Discovery reveals what services and endpoints exist, while execution performs the actual action with validated inputs. They should not share the same authority because visibility alone does not justify state change. Separating them keeps AI agents from turning enumeration into uncontrolled action.
Discovery and execution solve different problems in MCP tool design
Discovery is the control plane for understanding capability: what a server offers, how to reach it, and what a client may safely select. Execution is the data plane for performing a tool action with validated parameters. Keeping them separate prevents “I can see it” from becoming “I can do it,” which is the core safety boundary in MCP design.
That separation matters because discovery is often broad and low risk, while execution is where side effects, privilege, and state change appear. If a tool can be invoked through the same authority used to enumerate it, agents can turn harmless visibility into unintended action, especially when prompts, tool metadata, or downstream routing are manipulated.
MCP implementations therefore need different trust expectations for each phase. Discovery should expose enough metadata for selection and planning, but execution should require explicit authorization, input validation, and a tighter audience for tokens or credentials than the one used for catalog access. That is why many MCP security discussions focus on authorization boundaries rather than on tool listings alone, including MCP authorization for HTTP transports and the associated OAuth resource-server model.
Why conflating discovery with execution creates unsafe agent behaviour
When discovery and execution share authority, the tool catalog becomes an attack surface. An agent may inspect a service, infer that a tool exists, and then treat that metadata as permission to invoke it, even though enumeration only proves visibility. That is the classic confusion between observability and authority.
This is especially dangerous in agentic workflows where the model is choosing among tools, not a human clicking a button. Discovery can be influenced by prompt injection, misleading tool descriptions, or untrusted servers. If execution is not separately gated, a compromised planning step can cascade into state-changing action with the same trust that was granted for read-only awareness. The risk pattern is closely reflected in agentic AI guidance such as OWASP Agentic AI Top 10, which treats tool misuse and identity and privilege abuse as distinct concerns.
The practical test is simple: ask whether the action would still be acceptable if the discovery source were malicious or incomplete. If not, execution needs its own authorization path, its own validation rules, and its own logging trail.
Designing the boundary so tools stay useful without becoming overpowered
A good MCP design lets discovery be expressive without making it authoritative. Tool names, schemas, and capabilities should help the agent plan, but they should not imply blanket permission. Execution should verify the caller, scope the action to the minimum necessary context, and reject parameters that attempt to widen the blast radius.
In practice, that means keeping tool descriptions precise, binding execution to least privilege, and making state-changing operations explicit enough that they are easy to audit. For identity and credential handling, the same principle applies to machine auth patterns: the identity used to enumerate a server should not automatically inherit the rights to execute every tool on it. The issue aligns with broader guidance on MCP security and with non-human identity controls such as NHI Authentication Guide, where authentication and authorization are treated as separate design decisions.
When tool execution has side effects, a second rule is useful: if the call can change data, spend money, expose secrets, or trigger downstream automation, treat it as an execution event, not as a discovery follow-on. That distinction keeps planners honest and keeps dangerous actions from hiding inside apparently routine tool selection.
Risk and Threat Considerations
When discovery and execution are blurred, an attacker or malicious prompt can use harmless enumeration to reach privileged side effects. The main exposure is confused deputy behaviour, where a tool catalog, gateway, or agent planner is trusted to reveal capability but is accidentally allowed to authorise it too.
Failure mechanism: A server exposes tool metadata or discovery endpoints that are broader than its execution checks, or the same credential is accepted for both phases, so a client can move from “see” to “do” without a distinct authorization step.
Impact: That can produce unintended writes, command execution, secret exposure, or downstream automation abuse, especially in agentic systems that chain tool calls after a compromised planning step.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Discovery-to-execution confusion is a tool misuse boundary issue. |
| ASI03 — Identity & Privilege Abuse | Execution must not inherit discovery authority in agent tool design. | |
| Recommendation — Separate tool discovery from execution and enforce explicit authorization before any state-changing call. Bind each execution path to least privilege and revalidate the caller before action. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | MCP discovery and execution need distinct auth boundaries for machine clients. |
| NHI-05 — Overprivileged NHI | Shared authority across discovery and execution creates excess privilege. | |
| Recommendation — Use separate authentication and authorization checks for discovery and tool execution. Minimise tool credentials so enumeration rights do not imply execution rights. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Execution should receive only the access needed beyond discovery visibility. |
| IA-5 — Authenticator Management | MCP tool phases depend on credential handling and token scope discipline. | |
| AU-2 — Event Logging | Separating discovery and execution requires distinct auditability for state changes. | |
| Recommendation — Limit execution permissions to the smallest set of actions required for the tool. Scope and rotate credentials so discovery tokens cannot be reused for execution. Log execution events separately from discovery activity and retain traceable context. | ||
| NIST Zero Trust (SP 800-207) | AC-3 — Access Enforcement | Discovery visibility must not be mistaken for execution permission under zero trust. |
| AC-6 — Least Privilege | Zero trust requires narrower execution authority than read-only discovery. | |
| Recommendation — Enforce policy at the execution point rather than inheriting access from discovery. Apply least privilege so enumeration and action use different trust decisions. | ||
Practitioner Guidance
What to verify: Check that discovery responses never carry implicit execute rights, and that execution endpoints re-check authority independently of any catalog or registry access. If the same token can list tools and invoke them, the design is too permissive.
Decision rule: If the operation changes state, require explicit execution authorization, input validation, and logging even when the tool was already discovered successfully. If it is read-only, keep it in discovery-only scope unless the implementation can prove otherwise.
Common mistake: Teams often secure the MCP server and assume the tool list is therefore safe. The real boundary is not the server hostname, it is whether enumeration can be converted into action without a fresh trust decision.
Practitioner takeaway: Discovery should help an agent understand options, but execution should be the only place where the system decides whether an option is allowed to matter.
Related resources from NHI Mgmt Group
- What is the difference between an API and an MCP in agent tool design?
- What is the difference between field selection and returning full records in MCP tool design?
- What is the difference between privilege reduction and secret rotation?
- What is the difference between a rules-based secret scanner and a hybrid scanner?