--- title: "ApyHub MCP Server: Native API Discovery and Execution for AI Agents" url: https://apyhub.com/blog/apyhub-mcp-server-native-api-discovery-and-execution-for-ai-agents author: ApyHub published: 2026-07-19T20:36:00Z tags: [engineering, agents, mcp] --- # ApyHub MCP Server: Native API Discovery and Execution for AI Agents # ApyHub MCP Server: Native API Discovery and Execution for AI Agents ## Introduction The ApyHub MCP server gives AI agents direct, structured access to [ApyHub's certified API catalog](https://apyhub.com/catalog): agents search for the capability they need at runtime, evaluate the matches, and call the chosen API in the same flow. It is built on a search-and-use discovery pattern, so an agent never has to carry hundreds of tool definitions in its context to use one of them. That last part matters more than it sounds. Most of the API industry is currently answering the question "how do we make our catalog visible to agents" by exposing everything at once. This post explains why that approach breaks down, what MCP actually is, and how ApyHub's implementation works differently. ## What Is MCP? MCP (Model Context Protocol) is an open standard that lets AI systems connect to external tools and data sources in a structured, machine-readable way. Instead of a developer hand-wiring an integration for every service an agent might need, an MCP server exposes capabilities that any compatible agent runtime can discover and call. Claude, Cursor, and a growing set of agent frameworks speak it natively. In practical terms, MCP turns "here is our API documentation, good luck" into "here is a live interface your agent can query, understand, and execute against." The agent reads what a tool does, what inputs it expects, and what it returns, then decides whether and how to use it. That shift is why MCP adoption has moved so fast. Agents are no longer a demo pattern. They are composing real workflows across multiple services, and they need a consistent way to reach those services. ## The Retrofit Problem Here is where most implementations go wrong. The default way to make an existing catalog "MCP-ready" is to bolt an MCP endpoint onto it and expose every listing as a tool. Technically, this works. The agent connects and sees everything. Operationally, it fails, because of how agents actually consume context. Every tool definition an agent loads takes up space in its context window: the name, the description, the input schema, the output schema. Load a handful and it is negligible. Load a full catalog and it becomes the dominant cost of the session. Anthropic's engineering team has documented setups where tool definitions alone consumed over 130,000 tokens before the agent processed a single request, and cases where tool definitions and intermediate results ate 50,000+ tokens before the agent even read the task. The cost is not only tokens. An agent's attention is finite. Research on tool selection consistently shows that accuracy degrades as the number of in-context tools grows: the agent picks the wrong tool, confuses similar ones, or burns reasoning capacity just navigating the list. A thousand unused tool descriptions leave less room to think. A useful analogy: you don't load the entire internet into your head in order to search it. You ask when you need something. Agents should work the same way. This is why retrofitting fails as a strategy. Putting an MCP endpoint in front of a legacy catalog puts a modern label on a model designed for human browsing. The reality underneath has to change. ## How ApyHub's MCP Server Works: Search and Use ApyHub's MCP server is built directly on the catalog, and it follows the search-and-use pattern rather than the load-everything pattern. This is the same direction Anthropic itself has taken for large tool sets: its Tool Search approach defers tool loading and lets the agent discover tools on demand, which Anthropic reports preserves roughly 85% of the context that upfront loading would consume, while improving tool selection accuracy. On ApyHub, the flow looks like this: 1. **The agent connects once.** One MCP server, one authentication surface, covering the full catalog of 200+ APIs and 1,000+ endpoints. 2. **The agent searches at runtime.** When a task requires a capability, the agent queries the catalog for it: "convert docx to pdf," "validate IBAN," "extract text from image." 3. **The agent evaluates the matches.** Each result carries structured metadata: what the API does, its input and output schemas, its price in atoms, and its machine-readable certification (GDPR, SOC 2, ISO 27001 alignment, data residency, retention). 4. **The agent calls the chosen API.** Discovery and execution happen in the same system. No wrapper, no glue code, no preconfigured integration. Connecting looks like a standard MCP server entry in your agent's configuration: ```json { "mcpServers": { "apyhub": { "url": "https://api.apyhub.com/mcp", "headers": { "apy-token": "YOUR_APYHUB_TOKEN" } } } } ``` And a search-and-call sequence looks like this (illustrative payloads): ```json // Agent searches the catalog at runtime { "tool": "search_apis", "arguments": { "query": "convert docx to pdf", "limit": 20 } } ``` ```json // Catalog returns structured, comparable matches { "results": [ { "service_unikey": "convert-word-to-pdf", "service_display_name": "Document Conversion API", "endpoint_unikey": "convert-word-to-pdf", "endpoint_display_name": "Convert Word to PDF" } ], "total_count": 1 } ``` The agent's context holds only the search tool and the handful of definitions it actually retrieved, not the whole catalog. That keeps sessions cheap, fast, and accurate, and it means the catalog can keep growing without degrading every agent connected to it. ## What This Looks Like in Practice **A document pipeline that hits an unplanned step.** An agent processing invoices encounters a batch of scanned images instead of the expected PDFs. Mid-task, it searches the catalog for OCR, finds a text extraction endpoint, checks that its data residency matches the organization's EU requirement, and continues the pipeline. Nobody wired an OCR integration in advance, because nobody predicted needing one. **A workflow composed from multiple capabilities.** An onboarding agent takes a new customer record, validates the email, verifies the IBAN, enriches the company data, and generates a PDF summary. Four different APIs, one connection, one bill in atoms. In a per-vendor world, that same workflow means four integrations, four keys, and four subscriptions to manage. **An agent choosing between two similar APIs.** Two image processing endpoints solve the same problem. One is cheaper per call in atoms; the other retains no data and runs in the EU. The agent reads both certification artifacts and picks based on the policies it operates under, not on which one appeared first in a list. Comparison becomes something the agent does with data, at the moment of use. ## Why Native Matters Search-and-use is the discovery mechanism. What makes it work on ApyHub is that the layer underneath was designed for machine consumption in the first place. **Certification is machine-readable.** Every API in the catalog carries a structured certification artifact covering data handling, residency, retention, and standards alignment. A human can read a trust badge; an agent cannot. An agent can read a field. This is the difference between "verified by the platform" and certified in a form an autonomous caller can actually check before it acts. **Atoms give agents a cost signal.** Because every API is priced in the same unit, an agent can reason about cost across completely different services: a validation call versus an AI inference call versus a document conversion. Uniform pricing units turn cost from a billing surprise into a decision input. **One subscription, one auth surface.** The agent authenticates once and every certified capability in the catalog is callable. There is no per-API signup step for an agent to get stuck on, and no fragmented billing to reconcile afterwards. **Providers inherit agent-readiness.** Every API [published on ApyHub](https://apyhub.com/api-provider) is MCP-discoverable by default. Providers write no tool definitions and no wrappers; listing the API is what makes it callable by agents. None of these are things an MCP endpoint can add to a catalog retroactively. They are properties of the catalog itself. [**Explore the catalog →**](https://apyhub.com/catalog) ## Conclusion MCP made it possible for agents to reach external APIs. The open question was never the protocol; it was what the agent finds on the other side. A catalog dumped into context wholesale makes agents slower, costlier, and less accurate as it grows. A catalog an agent can search at runtime gets more useful as it grows. That is the bet behind [ApyHub's](https://apyhub.com/) native MCP server: agents that ask for what they need, when they need it, and get back capabilities they can verify before they call. Connect your agent to the catalog and the difference shows up in the first session. [**Try ApyHub →**](https://apyhub.com/) ## FAQ **What is the ApyHub MCP server?** It is a native MCP (Model Context Protocol) server built on top of the ApyHub API catalog. It lets AI agents search the catalog at runtime, evaluate matching APIs, and call them directly, without preconfigured integrations. **What is MCP in simple terms?** MCP is an open standard that lets AI agents connect to external tools and data in a structured way. Instead of a developer wiring each integration by hand, the agent discovers and calls capabilities through one consistent protocol. **Why doesn't ApyHub load all tools into the agent's context?** Loading hundreds of tool definitions consumes enormous context (Anthropic has documented setups exceeding 130,000 tokens on definitions alone) and measurably degrades tool selection accuracy. Search-and-use keeps only the relevant tools in context. **Which agent runtimes can connect to ApyHub's MCP server?** Any MCP-compatible client, including Claude, Cursor, and standard agent frameworks that support remote MCP servers. **Do agent calls cost the same as regular API calls?** Yes. Calls made by an agent through MCP consume atoms exactly like calls made from application code, under the same subscription. **Can an agent check compliance before calling an API?** Yes. Every API carries machine-readable certification metadata (GDPR, SOC 2, ISO 27001 alignment, data residency, retention), so an agent can evaluate whether a service meets its organization's requirements before executing a call. **Do providers need to do anything to make their APIs agent-ready?** No. Every API published on ApyHub is MCP-discoverable by default. Providers do not write tool definitions, wrappers, or glue code. **Is search-and-use an ApyHub invention?** No, and that is the point. It is the direction the ecosystem is converging on for large tool sets; Anthropic uses the same deferred-loading pattern in its own tooling. ApyHub applied it to a certified API catalog. ## About ApyHub [ApyHub](https://apyhub.com/) is the distribution and consumption layer for APIs: a curated, certified catalog that developers and AI agents use as a trusted operational layer. The catalog spans 1,500+ APIs, available under a single subscription priced in atoms, ApyHub's unified usage unit. Every API ships with machine-readable certification covering GDPR, SOC 2, and ISO 27001 alignment, and every endpoint is MCP-ready by default. ApyHub is headquartered in Amsterdam, with offices in the Netherlands, Greece, and India, and serves 65,000+ monthly developer workspaces . The free tier requires no card. Building an API? [Become a provider →](https://apyhub.com/api-provider)