MCP Tool Catalogs for Agent Pilot Readiness
Before connecting an agent to MCP servers, build a tool catalog that names each capability, owner, schema, approval class, and retirement path.
Pilot Surface
The MCP server is not the control plan.
Model Context Protocol makes it easier for agents and AI applications to discover tools, resources, and prompts from external systems. That is useful infrastructure. It is not, by itself, a decision about which capabilities belong in a production workflow.
The operating work starts one level above the protocol. A team needs a catalog that explains what each MCP tool can do, which business object it touches, which credential it uses, who owns the result, what approval is required, and how the capability should disappear when the pilot changes shape.
Our bias is to write the catalog before the first impressive demo. If the tool cannot be described in business language, it probably should not be available to an agent that is about to influence customer, finance, employee, compliance, or production records.
Old Pattern
Most pilots treat tool discovery as readiness.
The familiar technical path is fast: stand up an MCP server, expose a few functions, confirm the agent can list tools, and let the workflow call what it needs. That proves connectivity. It does not prove the organization understands the authority surface it just created.
MCP's tool discovery flow gives clients metadata such as tool names, descriptions, and input schemas. Those fields are a strong starting point, but they are not enough for launch governance because they do not answer the local operating questions.
A tool name is not an owner
The catalog should name the business owner who can approve the capability, answer policy questions, and decide whether a failed run should be retried, repaired, or escalated.
A schema is not a boundary
The input schema documents parameters. The catalog still has to define allowed record types, blocked fields, rate limits, stale-data behavior, and the cases that must pause for review.
A server list is not a launch set
An MCP server may expose more than one useful capability. The pilot should promote only the tools required for the workflow phase, not every callable action the server can provide.
Catalog Shape
Use seven fields that operators can inspect.
A workable MCP tool catalog should be compact enough for a weekly pilot review and precise enough for engineering, security, and the workflow owner to make the same decision. The point is not to recreate API documentation. The point is to translate capabilities into operational authority.
Capability
Name the tool in plain language and include the exact MCP tool identifier so reviewers can connect the business decision to the callable surface.
Business object
State whether the tool touches a ticket, invoice, opportunity, contract, employee record, vendor profile, production incident, or another object the business already owns.
Source and credential
Record the system of record, credential class, environment, and whether the tool reads, drafts, routes, updates, deletes, or triggers a downstream workflow.
Approval class
Separate no-review reads, packet-building work, reviewer-approved side effects, and actions that are out of scope for the current pilot.
Evidence returned
Describe what the tool returns to the agent and which source links, timestamps, or IDs must remain visible in the approval packet or trace.
Failure behavior
Define timeouts, partial results, conflicting records, unavailable tools, and the fallback queue that receives a blocked case.
Retirement trigger
Name the condition that removes or narrows the tool: permission drift, low usage, high reviewer edits, repeated errors, changed policy, or a completed pilot phase.
Example
A vendor onboarding agent needs a smaller catalog than the platform exposes.
Consider a vendor onboarding workflow. The company already has a procurement system, security questionnaire repository, contract folder, finance vendor record, and Slack escalation channel. An MCP layer can make those surfaces easier for an agent to reach, but the first pilot should not expose every action.
A useful catalog might approve read-only vendor profile lookup, security evidence retrieval, questionnaire packet drafting, missing-field detection, and routing to the procurement owner. It might require human approval before creating a vendor record or sending a message to the supplier. It should keep payment detail changes, contract commitment language, and vendor-risk overrides out of scope.
That catalog changes the pilot conversation. Instead of asking whether the agent can use procurement tools, the team can ask whether this exact onboarding packet has enough evidence to move from draft to review.
Protocol Fit
Map MCP primitives to the workflow, not the other way around.
MCP separates executable tools from resources that provide context and prompts that structure interactions. That separation is helpful because many workflows fail when context access and action authority are treated as the same thing.
For pilot design, resources should usually arrive before write tools. Let the agent retrieve approved context, build a packet, and show how it reasons about missing evidence. Then add narrow tools for routing or low-risk updates. Keep irreversible, customer-facing, financial, or policy-changing actions behind explicit approval until the review history is boring.
Resources first
Expose policy docs, schemas, runbook snippets, and source records in a way that lets the agent cite what it used without giving it write authority too early.
Tools second
Introduce executable actions only when the catalog has an owner, approval class, trace requirement, and rollback or repair path.
Prompts as workflow forms
Use reusable prompts to keep packets, exception summaries, and reviewer questions consistent across runs instead of relying on each agent turn to rediscover the format.
Controls
Keep guardrails next to the side effect.
Current agent frameworks are adding useful control primitives: tool guardrails, human review, resumable approvals, interrupts, and durable state. Those features help, but they should not be treated as a blanket safety layer around every tool.
The stricter control should live next to the side effect. If a tool can cancel an order, update a CRM field, create a vendor, change payment details, or send an external message, the catalog should require the tool-specific approval rule, validation, trace fields, and reviewer packet that make the action reconstructable later.
Validate before the call
Check required fields, stale context, blocked record categories, and policy thresholds before the agent reaches the tool call.
Pause before consequence
Use human review for sensitive MCP actions where the proposed change affects money, commitments, customer trust, employee data, or production systems.
Log after the result
Preserve the request, source evidence, approval decision, tool result, changed object, and recovery note as one run artifact.
Pilot Rhythm
Review the catalog like a backlog, not a policy binder.
The first catalog will be wrong in useful ways. Some tools will look important and never get called. Some read-only resources will become the real bottleneck because the agent cannot see the source record that operators rely on. Some approval rules will fire too often because the risk class was written too broadly.
Treat those observations as pilot data. Review the catalog weekly with engineering, security, and the workflow owner. Promote tools only when evidence shows the capability reduces coordination without hiding responsibility. Retire tools that create confusion, duplicate another source, or make reviewers ask for the same clarification every time.
The SolZero take is that MCP adoption becomes operationally useful when the catalog becomes the shared launch surface. The protocol connects systems. The catalog decides which connected capabilities the business is ready to trust.
Further reading