# MCP, registries, and getting your tools discovered

> Understand the difference between publishing a server, connecting it to a host, and getting a tool used.

Canonical: https://byagents.dev/humans/mcp-and-tool-discovery
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Guide
Level: Mixed
Outcome: Decide when an MCP integration helps and what publication alone cannot establish.

MCP—the Model Context Protocol—standardizes how compatible AI applications connect to servers exposing tools and context. It can make an integration easier to distribute across compatible hosts. It does not automatically bring your product into every agent’s tool list.

## Three separate milestones
**Publish:** The server and its metadata are available through a relevant distribution route. **Connect:** A host or user configures access to the server. **Use:** The agent selects a tool and completes a useful task. Report these milestones separately.

The MCP Registry provides metadata and installation information for clients and aggregators. A registry record can help a compatible consumer find a server; it is not the server runtime itself. Consult the current registry documentation for publication requirements and lifecycle status. [Registry overview](https://modelcontextprotocol.io/registry/about).

## Design tools around an intelligible job
A tool needs a clear name, description, input schema, and understandable results. The MCP tools specification defines tool listing and invocation, with schemas for inputs and optional structured outputs. These describe the interface; product usefulness still depends on the implementation. [MCP tools specification](https://modelcontextprotocol.io/specification/2026-07-28/server/tools).

Prefer a description that names the task and its important boundaries. “Extract invoice fields from an uploaded document; returns a job identifier” tells an agent more than “Ultimate document AI.” If completion requires another call, name and document that path. If an operation writes data or incurs a charge, make that clear before invocation.

## Avoid the thin-wrapper trap
Wrapping every API endpoint as a tool can expose too many overlapping choices. Start with a small useful workflow. Return the fields needed for the next decision rather than an enormous raw record. Errors should identify a recoverable next step without suggesting unlimited retries.

Anthropic’s tool-design guidance emphasizes clear tool descriptions, meaningful results, and evaluation against realistic tasks. Treat these as design practices to test in your environment, not a guarantee of tool selection. [Writing tools for agents](https://www.anthropic.com/engineering/writing-tools-for-agents).

## Authentication is part of the product
A host must be able to establish the correct access, and the operator must understand what is being authorized. Do not place secrets in public documentation or assume permission to perform a purchase because the tool exists. Verify the current host’s supported authentication and approval behavior before advertising compatibility.

A successful connection is also not a security certification. Review the protocol’s security guidance and your own application boundaries. Keep read-only discovery separate from actions that affect accounts, payments, or private data. [MCP security guidance](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices).

## When should you build an MCP server?
Build one when a defined group of users works in compatible hosts and a tool interface improves a real task. If the immediate problem is unreadable pricing or incomplete API documentation, solve that first. An existing API, useful guide, and working example may be a better initial distribution investment.

ByAgents currently publishes a read-only knowledge API and documentation, not a live MCP server. Its API contract diagnostic is a separate product capability. We make that distinction explicit so integrations can be chosen on facts.

## Check the protocol revision before copying an example

MCP behavior is versioned. This guide now links the 2026-07-28 tools and security documentation. A host or SDK may implement an older revision; that needs an explicit compatibility check, not an assumption. Use the [publication and compatibility recipe](https://byagents.dev/agents/mcp-publication-and-compatibility) to record the supported combination and distinguish known-server capability discovery from independent product discovery.

## Sources

- [MCP Registry](https://modelcontextprotocol.io/registry/about)
- [MCP tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)
- [Anthropic: Tool design](https://www.anthropic.com/engineering/writing-tools-for-agents)
- [MCP security](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices)

## Related reading

- [API documentation an agent can actually use](https://byagents.dev/humans/api-documentation)
- [From discovery to a purchase, booking, or API call](https://byagents.dev/humans/from-discovery-to-action)
- [What llms.txt and Markdown can—and cannot—do](https://byagents.dev/humans/llms-txt-and-markdown)
- [Recipe: publish and verify an MCP integration](https://byagents.dev/agents/mcp-publication-and-compatibility)
- [MCP, WebMCP, A2A, ACP, UCP, and ARD: what to build](https://byagents.dev/humans/agent-protocols-explained)