Give each integration a focused set of tools
One application can offer separate tool collections and agent identities for different jobs. Each has its own address and token audience, so integrations can discover a focused surface and keep their credentials tied to it.
Operation roles remain the authority for what the caller may do.
Example — Separate support from operations
A support integration sees lookup tools; an operations integration uses its own endpoint. A token issued for one endpoint cannot be replayed at the other.
For engineers
The backend assembly accepts resourceServerInstances. This excerpt is adapted from Wonder Todos’ existing declaration:
const resourceServerInstances: ResourceServerInstance[] = [
{
ref: 'support',
kind: ResourceServerKind.MCP,
displayName: 'Support',
description: 'Tools for looking up records.',
},
{
ref: 'concierge',
kind: ResourceServerKind.A2A,
displayName: 'Concierge',
description: 'An agent for application questions.',
actorSystemRefs: ['todo-assistant'],
},
];
Use the existing backend bootstrap imports for ResourceServerInstance and ResourceServerKind, and pass this array in its resourceServerInstances field. The actor reference must resolve to an exposable system registered by the application.
Assign operations to their tool server
On each selected operation, use mcp: { exposed: true, servers: ['support'], description: '…' }. Explicit membership is exclusive: that operation leaves the default /mcp catalogue and belongs to /mcp/support. An operation without named membership stays on the default surface.
For A2A, actorSystemRefs narrows the skills on the named agent card. An unresolved instance or system reference must not broaden the selection to the default catalogue.
Predict the default and named catalogues
A registered ACTOR system with an AGENTIC actor and an agentRef is eligible for the default A2A card. Giving concierge an actorSystemRefs list selects from those systems; it does not remove them from the default agent. Omitting that list on a named agent exposes all eligible systems on that named card. An unknown instance does not fall back to the default.
For the declarations above, assume todo-assistant is registered and a read operation is explicitly exposed with servers: ['support']:
| Declaration | Default endpoint | Named endpoint |
|---|---|---|
Read operation assigned to support | Absent from /mcp | Present on /mcp/support if the caller and operation are eligible |
| Exposed operation with no named membership | On /mcp if eligible | Absent from /mcp/support |
Eligible todo-assistant system listed by concierge | Still on the default A2A card | Also on the concierge card |
Another eligible system not listed by concierge | Still on the default A2A card | Absent from the concierge card |
Naming curates MCP membership exclusively, while A2A naming adds a separately addressed selection. Card or catalogue membership is still different from permission to invoke a business operation.
Obtain credentials for the intended address
Use the published instance audience when requesting a token, then call that instance. Audience matching confines an issued token; it does not decide which audiences a registered client is allowed to request. Use roles to deny business operations, and named instances to curate discovery and separate issued credentials.