MCP has a enterprise issue; The ‘Look before you leap’ problem
July 21, 2026
Why autonomous agents need a sneak peek at the server and a memory of previously seen capabilities
The first mover disadvantage
Introduction
OAuth, OIDC, JWT-based client authentication, token exchange, and workload identities provide strong mechanisms for proving identity and granting access. They do not, however, solve the problem that comes before authorisation: how an autonomous agent determines which MCP server is relevant to its goal.
This distinction becomes important in an enterprise architecture where many independently owned MCP servers are exposed through a centralised MCP gateway. The gateway can standardise authentication, policy enforcement, routing, auditing, and protocol handling. Yet if the gateway exposes only protected endpoints and authorisation metadata, the agent may still have to authenticate before it knows what each server can do.
Goal → Gateway → Authenticate → Not useful → Try another server
The result is technically secure authentication combined with structurally poor authorisation. Tokens are issued before relevance is established, users or administrators may approve unnecessary access, and the platform creates trust relationships with servers that the agent may never invoke.
In an enterprise setting this can cause significant barriers to entry for autonomy in Agentic systems, with a need to exert explicit control on Agent MCP relationship. Explicit server descriptions within the Agentic application can improve this problem but also provides an issue of server staleness and scale. You cant have a Devops team dedicated to updating agent descriptions of servers, to align to new MCP server standards.
A centralised MCP gateway could help here, by provide two additional primitives. First, it should expose a limited server synopsis or catalogue entry that allows agents to understand the broad purpose of each server before requesting operational authority. Second, the agent platform should maintain a durable but non-authoritative memory of MCP servers and capabilities it has previously encountered controlled by server metadata, so future planning can begin from known possibilities rather than rediscovering the environment from scratch every time.
For the purpose of this article, I am considering enterprise MCP applications using HTTPS transport, rather than personal clients such as Claude Desktop or Cursor. Dynamic client registration and Client ID Metadata Documents are therefore outside its scope.
SEP-2575 improves server discovery
SEP-2575 changes the MCP interaction model by removing the mandatory stateful initialisation handshake and replacing its functions with discrete stateless mechanisms. Protocol version and client capabilities move into individual requests, while a new server/discover RPC allows a client to inspect a server before invoking its operational capabilities.
The request is deliberately simple:
{
"jsonrpc": "2.0",
"id": "discover-1",
"method": "server/discover",
"params": {}
}
The response provides supported MCP versions, protocol capabilities, implementation information, and optional natural-language instructions:
{
"jsonrpc": "2.0",
"id": "discover-1",
"result": {
"supportedVersions": [
"2025-06-18"
],
"capabilities": {
"tools": {
"listChanged": true
},
"resources": {
"subscribe": false
}
},
"serverInfo": {
"name": "staff-operations-mcp",
"version": "2.4.1"
},
"instructions": "Provides staff server capabilities."
}
}
Servers must implement server/discover, although clients are not required to call it before other methods. Its primary purpose is to advertise supported protocol versions and server capabilities without coupling that exchange to a persistent initialisation lifecycle.
This is a significant improvement. A client can now understand a known server before completing a full MCP interaction.
Known server -> server/discover -> Evaluate compatibility -> Obtain authority
-> Invoke
However, it addresses only part of the look-before-you-leap problem.
server/discover answers:
Given this endpoint, what does the server support?
It does not answer:
Which endpoint should the agent approach for this goal?
The agent must already know that the server exists, where it is located, and that it is a plausible candidate. This is manageable when an application has one or two statically configured MCP servers. It becomes harder when an enterprise gateway exposes tens or hundreds of independently owned capabilities.
SEP-2575 moves discovery before initialisation. It does not provide ecosystem-level discovery before server selection.
Autonomous agents do not begin with a known server
OAuth is strongest when the destination, intended operation, and required authority are already known.
Known resource -> Known purpose -> Known permissions ->
Authorisation -> Invocation
Autonomous agents often begin with an outcome rather than a destination.
Goal -> Required capability -> Candidate servers -> Server selection ->
Narrow authorisation -> Invocation
A request such as “find the total number of holiday hours available” identifies the required outcome, but not necessarily the MCP server that provides it. The agent may need to compare multiple servers on the gateway, before finding the required resource.
If the gateway exposes only protected MCP endpoints, the agent has several poor options.
The impossible triangle of Autonomous sever discovery
It can maintain a static list of server-to-capability mappings inside the application, tightly coupling the agent to the enterprise MCP landscape. It can ask a model to infer capability from endpoint names, which is unreliable and potentially unsafe. Or it can authenticate to each candidate, call server/discover, and discard the servers that prove irrelevant.
Candidate A -> Authorise -> Discover -> Reject
Candidate B -> Authorise -> Discover -> Reject
Candidate C -> Authorise -> Discover -> Select
The final server-specific token may be narrowly scoped and correctly audience-bound. The architecture has still created unnecessary authorisation relationships.
The consequences include:
- token proliferation for servers that are never used;
- user or administrator approval before relevance is established;
- generic scope requests because the intended capability is unknown;
- additional metadata resolution, token exchange, and network latency;
- a larger trust surface across issuers and protected resources;
- audit trails that mix exploratory discovery with operational access.
Strong authentication does not remove this contradiction. It can produce many technically correct credentials for resources that were never relevant.
The gateway should provide the first discovery layer
A centralised MCP gateway is well positioned to solve the initial selection problem because it already knows which servers are registered, how they are routed, who owns them, which identity profiles they require, and which organisational policies apply.
The gateway should expose a deliberately limited synopsis of each server before server-specific operational authorisation occurs.
Agent goal -> Search gateway catalogue -> Select candidate ->
Call server/discover -> Evaluate trust -> Obtain narrow authority ->
Discover authorised tools -> Invoke
The gateway and server/discover perform different roles:
- Gateway synopsis = Which server may be relevant?
- server/discover = What does the server currently support?
- Authenticated MCP server = What can you actually do?
A gateway search request could describe the required capability rather than naming a server:
{
"capability": {
"domain": "staff operations",
"action": "actions.read"
},
"constraints": {
"environment": "production",
"dataResidency": "EU",
"identityMode": "delegated_user"
},
"limit": 5
}
The gateway applies deterministic visibility, trust, and policy filtering before returning candidates:
{
"generatedAt": "2026-07-21T08:30:00Z",
"matches": [
{
"serverId": "mcp.staff.operations",
"displayName": "Staff Operations",
"description": "Provides staff operation requires, around actions they can perform",
"owner": {
"domain": "Staff Operations",
"team": "HR Platforms"
},
"capabilities": [
{
"id": "staff.actions.read",
"operationType": "read",
"risk": "low"
},
{
"id": "staff.actions.write",
"operationType": "write",
"risk": "high"
}
],
"authorisation": {
"supportedModes": [
"delegated_user",
"workload"
]
},
"dataHandling": {
"classification": "confidential",
"residency": [
"EU"
],
"containsPersonalData": true
},
"trust": {
"status": "approved",
"productionApproved": true
},
"discovery": {
"href": "/mcp/servers/mcp.staff.operations/discover"
},
"metadata": {
"synopsisVersion": "7",
"lastValidatedAt": "2026-07-21T08:20:12Z",
"maxAgeSeconds": 300
}
}
]
}
This provides enough information for server selection without returning business data, complete tool schemas, internal hostnames, privileged operations, or identity-specific entitlements.
The synopsis is descriptive, not authoritative.
Server is discoverable ≠ Server is trusted
Server is trusted ≠ Caller is authorised
Caller is authorised ≠ Every tool is available
The live MCP server remains authoritative for the exact tools and resources available to the current identity.
Progressive disclosure
A gateway catalogue can itself become an attack surface if it exposes complete server inventories, administrative operations, implementation versions, internal routes, or tool schemas.
Discovery should therefore be progressive.
Gateway catalogue -> Broad purpose and capability categories
server/discover -> Protocol support and safe server details
Operational authorisation -> Exact identity-specific tools and schemas
A general catalogue might reveal only:
{
"serverId": "mcp.identity.operations",
"displayName": "Identity Operations",
"description": "Provides controlled identity-lifecycle capabilities.",
"capabilityCategories": [
"identity.read",
"identity.lifecycle"
],
"risk": "high",
"detailsRestricted": true
}
It should not expose privileged tool names, backend URLs, implementation details, or complete schemas unless the requesting workload has a legitimate need to inspect them.
The catalogue should normally require an existing enterprise user or workload identity. That credential permits access to the discovery plane, not to every server returned by it.
Gateway discovery token
Audience: MCP gateway
Purpose: Search permitted catalogue entries
Operational token
Audience: Selected MCP server
PurposeL: Invoke approved capabilities
The gateway token must not be passed through to downstream MCP servers. Once the agent selects a server, the platform obtains separate resource-specific authority.
Where detailed server metadata is also sensitive, the gateway can proxy server/discover using a dedicated discovery-only workload identity. That identity may inspect server metadata but must not be able to invoke tools or read protected resources.
Capability memory
The gateway catalogue solves initial discovery, but autonomous agents also need continuity.
An agent that has successfully used a server should not need to rediscover the complete enterprise capability landscape for every similar task. The platform can retain a lightweight memory of where capabilities were previously found.
{
"gatewayId": "enterprise-mcp-eu",
"serverId": "mcp.staff.operations",
"capabilities": [
"staff.operations.read",
"staff.operations.write"
],
"authorisationMode": "delegated_user",
"identityBinding": {
"tenant": "workspace-eu",
"workload": "hr-service-agent"
},
"capabilityVersion": "cap-41",
"lastValidatedAt": "2026-07-21T08:20:12Z",
"expiresAt": "2026-07-21T12:20:12Z"
}
This is not conversational memory and it is not a credential cache. It should not contain access tokens, refresh tokens, business data, tool results, client secrets, or reusable authority.
It tells the planner:
- Where a capability was previously found
- What kind of authority was previously required
It does not establish:
- A ongoing trust relationship with the server
- That the server capability still exists
- That the current identity with the server is still valid
- That a specific action or tool is currently authorised
Before execution, the platform must re-evaluate trust, obtain fresh server-specific authority, inspect the live MCP interface, and enforce current policy.
Remembered capability must never become remembered authority.
Gateway-controlled capability-memory TTL
The difficult part of agentic capability memory is staleness.
A stable, versioned server may expose the same broad capabilities for many months. A server under active development may change weekly. A sensitive administrative server may require remembered information to be discarded after a single session.
The agent cannot determine this reliably on its own. The gateway should have registered details around the volatility and risk of its servers and should therefore control the maximum lifetime of remembered capability metadata.
After an authenticated server interaction, the gateway could return a capability-memory policy:
{
"capabilityMemory": {
"capabilityVersion": "cap-41",
"issuedAt": "2026-07-21T08:30:00Z",
"maxAgeSeconds": 86400,
"inactivityTimeoutSeconds": 14400,
"revalidationRequired": true,
"revalidationUri": "/mcp/servers/mcp.staff.operations/discover",
"binding": {
"tenant": "workspace-eu",
"workload": "hr-service-agent"
},
"usage": "server_ranking",
"deleteOn": [
"capability_version_changed",
"server_trust_revoked",
"identity_binding_changed"
]
}
}
The gateway defines:
- How long the capability description may be retained;
- Which user, tenant, workload, or role it applies to;
- The capability version that was observed;
- Whether revalidation is required before reuse;
- Whether inactivity should expire the record;
- Which events require immediate refresh or deletion;
- Whether the memory may support server ranking only or broader planning.
The agent host enforces these rules deterministically. The model may query the record during planning, but it should not decide whether expired or revoked metadata remains usable.
The TTL is a maximum planning lifetime. It is not a token lifetime or an authorisation guarantee.
Capability memory remains valid ≠ Access token remains valid ≠
User remains entitled ≠ Tool invocation is authorised
This distinction allows stable servers to reduce repetitive discovery while allowing rapidly changing or sensitive servers to force frequent revalidation.
This does not completely fix a limitation of gateway catalogues: the catalogue and agent memory can both become stale. Explicit capability versions, validation times, and server-controlled TTLs make that staleness visible and enforceable rather than leaving it to uncontrolled local caching.
Discovery, trust, authorisation, and execution
The complete architecture separates four events.
Discovery: The agent uses capability memory and the gateway catalogue to identify plausible servers.
Trust: Deterministic policy verifies the server, publisher, route, hosting region, authorisation issuer, and security profile.
Authorisation: The platform obtains delegated, workload, or hybrid authority for the selected resource and purpose.
Execution: The live MCP server returns the current identity-specific interface and enforces policy for every invocation.
Capability memory -> Gateway discovery -> server/discover -> Trust evaluation
-> Narrow authorisation -> Live tool discovery -> Execution
The model reasons about functional suitability. The gateway controls enterprise visibility. server/discover describes a known server. Identity systems authenticate users and workloads. OAuth grants authority. The MCP server controls execution.
Benefits and limitations
This model reduces exploratory authorisation because tokens are requested only after a serious candidate has been selected. It improves least privilege because the intended capability is known before authority is requested. It also reduces latency, approval fatigue, repeated discovery, and coupling between agent applications and independently managed MCP servers.
However, both catalogue metadata and agent memory can become stale. Capability summaries can expose sensitive enterprise architecture if progressive disclosure is poorly designed. Remembered servers may bias an agent towards familiar options even when better capabilities become available. The gateway also becomes an important control plane requiring strong availability, governance, tenant isolation, registration controls, and audit.
These risks reinforce the central rule:
Discovery metadata and capability memory may influence selection, but they cannot replace current trust evaluation, authorisation, or live MCP enforcement.
Conclusion
A centralised MCP gateway can decouple agent applications from independently operated MCP servers and provide a consistent enterprise boundary for authentication, policy, routing, and audit. That architecture remains incomplete when an agent can discover only how to authenticate, but not which protected server is relevant.
SEP-2575 improves the MCP lifecycle by introducing server/discover, allowing clients to inspect the supported versions and capabilities of a known server without relying on the previous mandatory initialisation handshake. It moves discovery earlier, but it does not solve how an autonomous agent finds the correct server in a large enterprise environment.
The gateway should therefore provide the first discovery layer: a controlled catalogue of approved server synopses containing enough information for candidate selection but not enough to expose protected operations or create authority.
Once selected, server/discover can provide live server-level information. Operational OAuth should occur only after the resource and intended capability are known. Exact tools and identity-specific availability should remain behind fresh authorisation and live MCP policy.
Agents can also retain non-authoritative capability memory to improve future planning. That memory must remain identity-bound, versioned, revocable, and strictly separate from credentials. Its lifetime should be controlled by the server through explicit TTL and revalidation metadata.
The gateway makes servers findable. server/discover makes them understandable. Capability memory makes discovery reusable. Only fresh authorisation makes execution permissible.