--- review_count: 2 title: "Application Programming Interface (API) Context Hubs, Retrieval-Augmented Generation, and the Model Context Protocol: How Agents Discover and Use APIs" added: 2026-03-20T07:48:58+00:00 status: completed priority: high # low | medium | high blocks: [] started: 2026-03-20T07:48:58+00:00 completed: 2026-03-20T07:48:58+00:00 output: [knowledge] themes: [agentic-ai, memory-context, rag-retrieval, tools-infrastructure] cites: [] # slugs of items this item directly depends on or quotes related: [] # slugs of thematically connected items superseded_by: ~ # slug of a later item that overrides this one (null if not superseded) supersedes: ~ # slug of an older item this one replaces (null if not applicable) item_type: primary # primary | synthesis confidence: medium # high | medium | low versions: [] # entries: {version: "1.0", sha: "", changed: YYYY-MM-DD, progress: "", summary: ""} --- # Application Programming Interface (API) Context Hubs, Retrieval-Augmented Generation, and the Model Context Protocol: How Agents Discover and Use APIs ## Research Question What approaches are being used to enable Artificial Intelligence (AI) agents to discover, understand, and invoke external Application Programming Interfaces (APIs), and how do the three major emerging strategies -- context hubs (exemplified by Andrew Ng's `context-hub`), Retrieval-Augmented Generation (RAG)-based API discovery, and the Model Context Protocol (MCP) -- compare in their design choices, trade-offs, and scope? Is the core problem that `context-hub` addresses being solved in meaningfully different ways elsewhere, or do these approaches converge? Supporting questions: - What specific problem does `andrewyng/context-hub` solve, and what is its design model? - How does RAG-based API discovery work, and what prior work exists (e.g., Representational State Transfer (REST)-GPT, Gorilla, ToolBench)? - What is MCP, what problem does it solve, and what does its scope overlap with or differ from context hubs and RAG-based tooling? - What are the key design axes across these approaches (static vs. dynamic discovery, structured vs. unstructured context, push vs. pull, standardised vs. proprietary protocol)? - What gaps remain unaddressed across all three approaches? ## Scope **In scope:** - `andrewyng/context-hub` -- architecture, intended use case, and design decisions - MCP (Anthropic, 2024) -- protocol specification, current adoption, and ecosystem - RAG-based API/tool discovery research: Representational State Transfer (REST)-GPT, Gorilla Large Language Model (LLM) benchmark, ToolBench / ToolLLM, HuggingGPT, and related academic work - OpenAPI / Swagger as a structured API description layer relevant to all three approaches - Agent frameworks that bridge these approaches: LangChain tools, LlamaIndex tool use, AutoGPT plugins, OpenAI function calling / tool use - Commercial API discovery products and analogues: Postman AI, RapidAPI AI search, Amazon Web Services (AWS) Bedrock Agents action groups - Prior completed research in this repository that is directly adjacent: any items tagged with `rag`, `mcp`, or `agents` **Out of scope:** - Detailed implementation of a new API discovery system (this is a research item) - API gateway infrastructure, rate limiting, or API management platforms (Kong, Apigee) unless directly tied to agent discovery - Non-AI API catalogues and developer portals (Swagger Hub, ReadMe.io) unless compared as a baseline - Security vulnerabilities in specific API implementations (a separate concern from discovery architecture) **Constraints:** Publicly accessible sources. GitHub repository documentation, arXiv preprints, official protocol specifications, and vendor documentation (2022-2026). Web search at retrieval time for the most current state of `context-hub` and MCP ecosystem, as both are evolving rapidly. ## Context AI agents are increasingly expected to use external tools -- web search, code execution, data retrieval, and arbitrary APIs -- to complete tasks. The core challenge is: *how does an agent know what tools exist, what they do, and how to call them correctly?* Three distinct strategies have emerged in parallel: 1. **Context hubs** -- curated, structured documents that describe APIs in a format optimised for LLM consumption. Andrew Ng's `context-hub` (https://github.com/andrewyng/context-hub) is a prominent public example. The model is essentially: give the LLM a well-structured API reference at prompt time, let it reason about how to call the API. 2. **RAG-based tool discovery** -- rather than providing all API documentation upfront, retrieve the relevant portion at query time. Research projects like Gorilla (Berkeley, 2023) and ToolBench (2023) train or prompt models to retrieve correct API calls from a large indexed catalogue. This scales better than context hubs but requires a retrieval index and introduces retrieval failure modes. 3. **Model Context Protocol (MCP)** -- Anthropic's 2024 open protocol for LLM-tool integration. MCP defines a standardised wire format for tool servers to expose capabilities to any compliant LLM client. Rather than baking tool knowledge into context, MCP externalises it into discoverable, invocable servers. It is closer in spirit to a remote-procedure-call style protocol than a documentation format. These three approaches are not mutually exclusive -- an MCP server could use RAG internally to decide which sub-tools to expose; a context hub could be served via MCP. But they represent different philosophical starting points: documentation quality, retrieval accuracy, and protocol standardisation respectively. The issue that seeds this item explicitly asks whether `context-hub` is solving a problem that is being addressed in different manners elsewhere. This is the central question to answer. ## Approach 1. **Characterise `context-hub`** -- read the `andrewyng/context-hub` repository README, any associated documentation, and public discussion. What is the exact problem statement? What is the data model for a "context hub"? Who are the intended consumers (agents, humans, both)? What APIs are already represented? 2. **Map the RAG-based API discovery landscape** -- survey key research papers: Gorilla (Patil et al., 2023), ToolBench/ToolLLM (Qin et al., 2023), REST-GPT (Song et al., 2023), HuggingGPT (Shen et al., 2023). For each: what problem does it solve, what is the corpus, and how does retrieval work? 3. **Characterise MCP** -- read the Anthropic MCP specification (https://modelcontextprotocol.io), the GitHub repository (https://github.com/modelcontextprotocol), and the current server ecosystem. What is in-scope for MCP vs. out-of-scope? How does discovery work within MCP -- does a client know what servers exist? 4. **Design axis comparison** -- map all three approaches across key axes: static vs. dynamic context, structured vs. unstructured API description, push (context in prompt) vs. pull (retrieval or protocol call), proprietary vs. open standard, training-time vs. inference-time knowledge, human-authored vs. auto-generated tool descriptions. 5. **Gap analysis** -- what problems does none of the three approaches address well? Likely candidates: cross-API orchestration, API versioning and drift, authentication and credential management within agent context, cost-aware tool selection, privacy-preserving tool use. 6. **Convergence / divergence assessment** -- is the field converging on a single dominant approach, or are context hubs / RAG / MCP targeting different segments of the problem space that are complementary rather than competing? 7. **Synthesis** -- produce Executive Summary, Key Findings, and Evidence Map. ## Sources - [x] [`andrewyng/context-hub`](https://github.com/andrewyng/context-hub) — repository README and linked documentation - [x] [Anthropic MCP specification](https://modelcontextprotocol.io) — protocol overview and specification - [ ] [MCP GitHub organisation](https://github.com/modelcontextprotocol) — server ecosystem and community - [x] Gorilla paper -- Patil, S. et al. (2023) -- "Gorilla: Large Language Model Connected with Massive APIs" -- arXiv:2305.15334 - [x] ToolBench / ToolLLM -- Qin, Y. et al. (2023) -- "ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs" -- arXiv:2307.16789 - [x] REST-GPT -- Song, Y. et al. (2023) -- "RestGPT: Connecting Large Language Models with Real-World RESTful APIs" -- arXiv:2306.06624 - [x] HuggingGPT -- Shen, Y. et al. (2023) -- "HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in HuggingFace" -- arXiv:2303.17580 - [x] API-Bank -- Li, M. et al. (2023) -- "API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs" -- arXiv:2304.08244 - [x] [OpenAPI Specification](https://swagger.io/specification/) — the structured API description standard underlying most tool integration work - [x] [LangChain tools documentation](https://python.langchain.com/docs/modules/agents/tools/) — current tool and MCP adapter navigation - [ ] [OpenAI function calling / tool use documentation](https://platform.openai.com/docs/guides/function-calling) — attempted; inaccessible without authentication from this environment - [x] Survey of LLM tool use -- Qu, Y. et al. (2024) -- "Tool Learning with Foundation Models" -- arXiv:2304.08354 --- ## Research Skill Output *(Full output from running the research skill -- retained verbatim in the completed item. Sections §0-§5 are the investigation; Section §6 seeds the Findings section below.)* ### §0 Initialise - **[fact]** The research question is whether `context-hub`, RAG-style API discovery, and MCP are alternate solutions to one problem or complementary solutions to different layers of the same problem: helping agents discover, understand, and correctly invoke external APIs. Source: `https://raw.githubusercontent.com/davidamitchell/Research/main/Research/completed/2026-03-18-api-context-hubs-rag-mcp.md`. - **[fact]** The scope includes `context-hub`, the live MCP specification and client-support pages, the main academic tool-use systems (Gorilla, ToolLLM / ToolBench, REST-GPT, HuggingGPT, API-Bank), the OpenAPI Specification (OAS), and directly adjacent completed repository items on context management, memory, and MCP. Source: `https://raw.githubusercontent.com/davidamitchell/Research/main/Research/completed/2026-03-18-api-context-hubs-rag-mcp.md`. - **[fact]** The prior completed items consulted here are `2026-03-01-context-mode-llm-context-compression.md`, `2026-03-02-agent-memory-management-context-injection.md`, `2026-03-08-self-hosted-mcp-server-options.md`, and `2026-03-08-context-engineering-first-principles.md` because they establish that context is scarce, RAG is retrieval rather than a full architecture, MCP has concrete transport and security boundaries, and prompt-time context quality directly shapes agent behaviour. Sources: `https://raw.githubusercontent.com/davidamitchell/Research/main/Research/completed/2026-03-01-context-mode-llm-context-compression.md`; `https://raw.githubusercontent.com/davidamitchell/Research/main/Research/completed/2026-03-02-agent-memory-management-context-injection.md`; `https://raw.githubusercontent.com/davidamitchell/Research/main/Research/completed/2026-03-08-self-hosted-mcp-server-options.md`; `https://raw.githubusercontent.com/davidamitchell/Research/main/Research/completed/2026-03-08-context-engineering-first-principles.md`. - **[fact]** The output format required here is a complete research record: decomposition, investigation, reasoning, consistency check, depth expansion, synthesis, recursive review, and a Findings section that adds no new claims beyond the synthesis. Source: `https://raw.githubusercontent.com/davidamitchell/Research/main/research-prompt.md`. - **[assumption]** The missing `.github/skills/research/SKILL.md` file means the fallback process described in `research-prompt.md` is the closest available implementation of the research skill. **Justification:** The repository instruction memory explicitly documents `research-prompt.md` as the fallback when the skill file is unavailable. Source: `https://raw.githubusercontent.com/davidamitchell/Research/main/research-prompt.md`. ### §1 Question Decomposition - **Branch A -- `context-hub` itself** - A1. What problem statement does `context-hub` make explicit? - A2. What is the content and metadata model of a context hub entry? - A3. Is `context-hub` primarily for humans, agents, or both? - A4. How does `context-hub` attempt to improve over time? - **Branch B -- RAG-based API discovery** - B1. What problem does each major system solve: Gorilla, ToolLLM / ToolBench, REST-GPT, HuggingGPT, and API-Bank? - B2. What corpus does each system search over or reason over? - B3. Where does retrieval happen: before tool selection, during planning, or during execution? - B4. What are the scale and freshness advantages relative to prompt-time documentation loading? - **Branch C -- MCP** - C1. What does MCP standardise? - C2. How do clients discover capabilities after connecting? - C3. What does MCP expose beyond tools? - C4. What does MCP explicitly not solve? - **Branch D -- Comparison axes** - D1. Static push vs. dynamic pull - D2. Documentation vs. retrieval vs. invocation protocol - D3. Human-authored vs. machine-indexed descriptions - D4. Curated small catalogue vs. large open catalogue - D5. Local agent memory vs. shared interoperability - **Branch E -- Gaps and convergence** - E1. What role does the OpenAPI Specification (OAS) play across all three approaches? - E2. Where do server discovery, trust, authentication, and version drift remain unresolved? - E3. Is the ecosystem converging on a layered stack or a single dominant architecture? ### §2 Investigation #### 2.1 Prior work cross-reference - **[fact]** `2026-03-01-context-mode-llm-context-compression.md` found that prompt-time context is expensive and that tool definitions plus tool outputs compete for the same finite context window. That prior result matters here because `context-hub` pushes more documentation into the context window while RAG and MCP reduce prompt-time loading by retrieving or invoking only what is needed. - **[fact]** `2026-03-02-agent-memory-management-context-injection.md` concluded that RAG is a retrieval mechanism rather than a complete memory architecture. That distinction matters here because RAG-based API discovery solves selection and grounding at scale, not interoperability by itself. - **[fact]** `2026-03-08-self-hosted-mcp-server-options.md` established that MCP is a transport and capability protocol with concrete deployment, authentication, and client-support constraints. That prior result matters because it frames MCP as runtime infrastructure rather than a documentation format. - **[inference]** The prior repository work already suggests a layered interpretation: prompt-time context curation, retrieval-time selection, and runtime invocation are separable concerns. #### 2.2 What `context-hub` solves - **[fact]** The `context-hub` README states its problem directly: "Coding agents hallucinate APIs and forget what they learn in a session." It positions Context Hub as a source of curated, versioned documentation that agents can fetch and reuse. Source: `https://raw.githubusercontent.com/andrewyng/context-hub/main/README.md`. - **[fact]** `context-hub` is explicitly designed for agent use rather than primary human use: the README says "Chub is designed for your coding agent to use (not for you to use!)." Source: `https://raw.githubusercontent.com/andrewyng/context-hub/main/README.md`. - **[fact]** The primary interface is a Command Line Interface (CLI): `chub search` finds entries and `chub get` fetches the relevant documentation, including language-specific variants such as `--lang py` and `--lang js`. Source: `https://raw.githubusercontent.com/andrewyng/context-hub/main/README.md` and `https://raw.githubusercontent.com/andrewyng/context-hub/main/docs/cli-reference.md`. - **[fact]** `context-hub` includes a local memory loop via annotations. `chub annotate` stores a note locally and appends that note automatically to future `chub get` results for the same entry. Source: `https://raw.githubusercontent.com/andrewyng/context-hub/main/docs/feedback-and-annotations.md`. - **[fact]** `context-hub` includes a shared quality loop via feedback. `chub feedback` sends up/down ratings and issue labels such as `outdated`, `incomplete`, or `wrong-version` back to maintainers. Source: `https://raw.githubusercontent.com/andrewyng/context-hub/main/docs/feedback-and-annotations.md` and `https://raw.githubusercontent.com/andrewyng/context-hub/main/docs/cli-reference.md`. - **[fact]** The content model is a documentation registry rather than a protocol. The content guide defines a directory structure of `author/docs/.../DOC.md` and `author/skills/.../SKILL.md`, with YAML Ain't Markup Language (YAML) frontmatter for `name`, `description`, `metadata.languages`, `metadata.versions`, `metadata.revision`, `metadata.updated-on`, `metadata.source`, and optional tags. Source: `https://raw.githubusercontent.com/andrewyng/context-hub/main/docs/content-guide.md`. - **[fact]** `context-hub` supports incremental fetch rather than mandatory whole-document loading. Entries may expose reference files, and agents can fetch a specific file with `--file` or fetch everything with `--full`. Source: `https://raw.githubusercontent.com/andrewyng/context-hub/main/docs/cli-reference.md`. - **[inference]** `context-hub` is best understood as a curated prompt-time knowledge distribution system plus a lightweight local memory mechanism, not as a runtime tool-invocation standard. - **[inference]** `context-hub` optimises for high-trust, human-authored API guidance on a bounded set of important APIs; it does not attempt to solve large-catalogue retrieval or inter-client interoperability. #### 2.3 How RAG-based API discovery works - **[fact]** Gorilla targets the problem of generating correct API calls. Its abstract says current LLMs struggle with accurate arguments and hallucinated API usage, and that Gorilla plus a document retriever adapts to test-time document changes and substantially mitigates hallucination. Source: `https://arxiv.org/abs/2305.15334`. - **[fact]** Gorilla introduces APIBench, a dataset built from HuggingFace, TorchHub, and TensorHub APIs. Source: `https://arxiv.org/abs/2305.15334`. - **[fact]** ToolLLM / ToolBench targets large-scale real-world tool use. ToolBench is built from 16,464 real-world Representational State Transfer (REST) APIs across 49 categories collected from RapidAPI Hub, and ToolLLaMA is paired with a neural API retriever. Source: `https://arxiv.org/abs/2307.16789`. - **[fact]** ToolLLM's solution path includes instruction generation, solution-path annotation, a depth-first-search decision tree algorithm for exploring reasoning traces, and retrieval of relevant APIs before invocation. Source: `https://arxiv.org/abs/2307.16789`. - **[fact]** REST-GPT addresses a more realistic scenario: connecting LLMs to real-world RESTful APIs described by OAS. The system uses a Planner, an API Selector, and an Executor, with coarse-to-fine online planning and response parsing based on the response schema in OAS. Source: `https://arxiv.org/abs/2306.06624` and `https://restgpt.github.io/`. - **[fact]** HuggingGPT is not primarily an open-web API catalogue system; it uses ChatGPT to plan tasks, select Hugging Face models from their function descriptions, execute subtasks, and summarise results. Source: `https://arxiv.org/abs/2303.17580`. - **[fact]** API-Bank frames tool use as three unsolved questions: how capable current models are, how to improve them, and what obstacles remain. It evaluates planning, retrieval, and calling over 73 API tools, 314 dialogues, 753 API calls, and a training set spanning 2,138 APIs from 1,000 domains. Source: `https://arxiv.org/abs/2304.08244`. - **[fact]** The survey "Tool Learning with Foundation Models" describes a general tool-learning loop in which models must understand the user instruction, decompose a task into subtasks, dynamically adjust a plan, and select appropriate tools for each subtask. Source: `https://arxiv.org/abs/2304.08354`. - **[inference]** RAG-based API discovery is not one algorithm but a family of retrieve-select-plan-call systems that move API knowledge lookup to inference time instead of embedding all relevant documentation directly into the prompt. - **[inference]** The main advantage of RAG systems over `context-hub` is scale and freshness: a retriever can search thousands of APIs and adapt to document changes without a human manually pre-loading the exact doc into the context window. - **[inference]** The main disadvantage of RAG systems relative to `context-hub` is that they add failure modes in retrieval quality, ranking, reasoning-path search, and execution planning. #### 2.4 What MCP standardises - **[fact]** MCP describes itself as an open-source standard for connecting AI applications to external systems, including data sources, tools, and workflows. Source: `https://modelcontextprotocol.io/introduction`. - **[fact]** MCP standardises connection lifecycle and capability negotiation. The lifecycle page defines initialization, operation, and shutdown phases, and requires clients and servers to exchange protocol version and capabilities during `initialize`. Source: `https://modelcontextprotocol.io/specification/latest/basic/lifecycle`. - **[fact]** MCP discovery inside an established connection is explicit and structured. Clients call `tools/list` to discover tools and `tools/call` to invoke them; tool definitions include `name`, `description`, `inputSchema`, and optional `outputSchema`. Source: `https://modelcontextprotocol.io/specification/latest/server/tools`. - **[fact]** MCP covers more than tools. Servers may expose resources with `resources/list` and `resources/read`, and may expose prompt templates with `prompts/list` and `prompts/get`. Source: `https://modelcontextprotocol.io/specification/latest/server/resources` and `https://modelcontextprotocol.io/specification/latest/server/prompts`. - **[fact]** MCP tool results can return text, images, audio, structured content, embedded resources, and links to resources identified by Uniform Resource Identifiers (URIs). Source: `https://modelcontextprotocol.io/specification/latest/server/tools` and `https://modelcontextprotocol.io/specification/latest/server/resources`. - **[fact]** The MCP clients page presents the ecosystem as broad and multi-client, listing support across assistant products, development tools, and other applications, and explicitly markets MCP as a build-once, integrate-everywhere protocol layer. Source: `https://modelcontextprotocol.io/clients` and `https://modelcontextprotocol.io/introduction`. - **[fact]** MCP security guidance requires input validation, access controls, rate limiting, output sanitization, client-side user confirmation for sensitive operations, and logging for audit purposes. Source: `https://modelcontextprotocol.io/specification/latest/server/tools` and `https://modelcontextprotocol.io/specification/latest/server/resources`. - **[inference]** MCP solves interoperability of runtime exposure and invocation after a client has connected to a server, but it does not itself define a universal global directory that tells a client which remote servers exist or which one to trust before connection. - **[inference]** MCP therefore standardises the contract between client and server, not the upstream problem of authoring API documentation, ranking among many candidate APIs, or discovering remote servers at internet scale. #### 2.5 The role of OAS and adjacent commercial systems - **[fact]** The OAS defines a standard, language-agnostic interface to Hypertext Transfer Protocol (HTTP) APIs that allows both humans and computers to discover and understand service capabilities without source code, prose documentation, or network-traffic inspection. Source: `https://swagger.io/specification/`. - **[fact]** RestGPT depends directly on OAS. Its public project page says the Caller reads the complete API documentation to organise parameters and the Parser uses the response schema defined in OAS. Source: `https://restgpt.github.io/`. - **[fact]** AWS Bedrock Agents action groups begin from an OpenAPI schema and even constrain resulting tool names to a format compatible with Anthropic tool-name requirements. Source: `https://docs.aws.amazon.com/bedrock/latest/userguide/agents-action-add.html`. - **[fact]** LangChain's current documentation surfaces both a `Tools` section and explicit `MCP Adapters`, which shows that mainstream agent frameworks treat tool schemas and MCP integration as connected but distinct layers. Source: `https://python.langchain.com/docs/modules/agents/tools/`. - **[inference]** OAS is the shared structural substrate across much of the field: context hubs can distill it into agent-readable docs, RAG systems can index and retrieve it, and protocol layers such as MCP or Bedrock action groups can expose operations derived from it at runtime. #### 2.6 Design-axis comparison - **[fact]** `context-hub` is a push-oriented system: agents fetch curated documentation up front and then reason from that documentation in the prompt. Source: `https://raw.githubusercontent.com/andrewyng/context-hub/main/README.md` and `https://raw.githubusercontent.com/andrewyng/context-hub/main/docs/cli-reference.md`. - **[fact]** Gorilla, ToolLLM, and related systems are pull-oriented systems: retrieval happens at query time against a larger catalogue and feeds into planning and calling. Source: `https://arxiv.org/abs/2305.15334`, `https://arxiv.org/abs/2307.16789`, and `https://arxiv.org/abs/2304.08354`. - **[fact]** MCP is a runtime protocol layer: the client first connects, negotiates capabilities, lists available tools/resources/prompts, and then invokes them. Source: MCP lifecycle, tools, resources, and prompts pages. - **[fact]** `context-hub` content is human-authored Markdown with YAML metadata, while ToolBench-style systems operate over machine-indexed large corpora of API descriptions and benchmarks, and MCP tool descriptors are structured schemas exposed by servers at runtime. Sources: `https://raw.githubusercontent.com/andrewyng/context-hub/main/docs/content-guide.md`, `https://arxiv.org/abs/2307.16789`, and `https://modelcontextprotocol.io/specification/latest/server/tools`. - **[inference]** On the primary design axis, the three approaches correspond to three different layers: `context-hub` is documentation curation, RAG is large-catalogue selection and grounding, and MCP is interoperable invocation. - **[inference]** The approaches therefore overlap in the user-visible goal of "help the agent use APIs correctly" while diverging in where they intervene: before context assembly, during retrieval and planning, or during runtime transport. #### 2.7 Remaining gaps - **[fact]** API-Bank's abstract states that obstacles remain even after training on large tool-use corpora, and its evaluation explicitly measures failure in planning, retrieving, and calling APIs. Source: `https://arxiv.org/abs/2304.08244`. - **[fact]** MCP's own security considerations require access controls, user confirmation, and audit logging, which implies that safe invocation is still an application responsibility rather than something the protocol fully solves. Source: `https://modelcontextprotocol.io/specification/latest/server/tools` and `https://modelcontextprotocol.io/specification/latest/server/resources`. - **[inference]** None of the three approaches fully solves internet-scale server discovery and trust. `context-hub` assumes a known registry of curated docs, RAG assumes a known indexed corpus, and MCP assumes the client already has a server to connect to. - **[inference]** None of the three approaches fully solves delegated authentication, policy-aware permissioning, and user-consent workflows across heterogeneous third-party services. MCP makes those needs explicit, but the application still has to implement them. - **[inference]** None of the three approaches fully solves API drift end to end. `context-hub` relies on content maintainers to refresh docs, RAG depends on index freshness and retriever quality, and MCP servers can still expose tool schemas that drift from the backing service behaviour. - **[inference]** Cross-API orchestration and cost-aware tool choice remain weak across the stack. The academic systems mostly benchmark correctness of planning and calling, not long-horizon operational trade-offs such as price, quota exhaustion, privacy boundaries, or organisational policy. ### §3 Reasoning - **[inference]** The strongest way to compare the three approaches is by asking what artefact each one standardises. `context-hub` standardises curated documentation artefacts, RAG systems standardise retrieval and selection pipelines over larger corpora, and MCP standardises runtime client-server interaction. - **[inference]** Once the comparison is framed at the artefact level, the apparent competition between the approaches weakens. A single production system can use all three without contradiction: OAS-derived docs in a context hub for common cases, RAG to choose among many candidate APIs, and MCP to invoke the chosen capability through a common protocol. - **[inference]** The repeated appearance of OAS across RestGPT, Bedrock action groups, and generic API tooling indicates that the field still depends on structured API descriptions even when the final user experience looks like free-form agent tool use. - **[inference]** The retrieval papers and benchmarks show that the central scaling problem is not merely "does the agent have documentation" but "can the agent choose the right documentation or tool from a very large universe at inference time." That is why RAG systems outperform prompt-time curation for breadth. - **[inference]** The MCP specification shows that runtime discoverability is local to the connection, not global to the ecosystem. That distinction explains a common confusion: MCP solves discovery of capabilities on a known server, not discovery of all possible servers on the internet. - **[assumption]** The current public `context-hub` repository is representative of the broader "context hub" design pattern. **Justification:** It is the public exemplar named in the item prompt, and its README, content guide, and feedback model are internally coherent enough to infer the pattern's design philosophy. ### §4 Consistency Check - **[fact]** There is no contradiction between saying MCP is discoverable and saying MCP does not solve global discovery. The specification clearly defines `tools/list`, `resources/list`, and `prompts/list` after connection, while leaving server selection outside the protocol. - **[fact]** There is no contradiction between saying RAG systems are dynamic and saying RestGPT reads full API documentation. The retrieval or planner can choose which document set to inspect, and the selected document may still be consumed in detail during execution. - **[fact]** There is no contradiction between saying `context-hub` is static curation and saying it improves over time. The improvement loop is mediated through local annotations and maintainer feedback, not through automatic internet-scale retrieval. - **[inference]** The evidence base consistently supports a layered-stack conclusion more strongly than a winner-take-all conclusion. ### §5 Depth and Breadth Expansion - **[inference] Technical lens:** `context-hub` optimises correctness through pre-curated structure, RAG optimises breadth and freshness through retrieval, and MCP optimises interoperability and runtime typing through schemas and negotiated capabilities. - **[inference] Economic lens:** `context-hub` has lower runtime complexity but higher human curation cost per supported API; RAG has higher infrastructure cost because it needs indexing, retrieval, and evaluation; MCP has server-development and operations cost but creates reuse across multiple clients once exposed. - **[inference] Historical lens:** The 2023 academic systems treated tool use mainly as a planning and retrieval problem over large API corpora, while the 2024-2026 MCP wave reflects a shift toward protocol standardisation and ecosystem interoperability. - **[inference] Behavioural lens:** `context-hub` shapes the model by improving what enters the prompt, RAG shapes the model by choosing what evidence is retrieved at the moment of need, and MCP shapes the model by constraining action surfaces into named tools, resources, and prompts. - **[inference] Security and governance lens:** MCP is the only one of the three that explicitly foregrounds access control, user confirmation, and auditability in its specification text, but it still leaves implementation details to clients and servers. `context-hub` and RAG mostly address correctness and grounding rather than permission boundaries. - **[inference] Strategic lens:** The likely market split is not one dominant architecture but a supply chain: curated high-value docs for repeated workflows, retrieval for long-tail discovery, and protocol-standardised invocation for production integration. ### §6 Synthesis **Executive summary:** - **[inference]** Application Programming Interface context hubs, RAG-based API discovery, and MCP solve different layers of the same agent-tooling problem rather than competing for a single winning architecture. - **[fact]** `context-hub` is a curated prompt-time documentation registry for agents: it distributes versioned, language-specific Markdown docs through a CLI and augments them with local annotations and maintainer feedback loops. - **[fact]** RAG-based systems such as Gorilla, ToolLLM / ToolBench, REST-GPT, and API-Bank shift API knowledge lookup to inference time, letting agents search large API corpora, adapt to document changes, and plan against retrieved evidence, but they introduce retriever, planner, and execution failure modes. - **[fact]** MCP standardises runtime interoperability after connection through capability negotiation and structured listing/calling of tools, resources, and prompts; it does not itself solve global server discovery, trust selection, or authoring of API knowledge. - **[inference]** The ecosystem is converging on a layered stack built around OAS and similar structured descriptions: curated docs for repeated high-trust use, retrieval for large-scale selection, and MCP-style protocols for interoperable invocation. **Key findings:** 1. **[fact]** `context-hub` solves a narrow but practical problem: agents hallucinate APIs and lose session-specific knowledge, so it provides curated, versioned documentation plus persistent local annotations and maintainer feedback to improve future runs. 2. **[fact]** `context-hub` is a documentation registry rather than a runtime protocol. Its content model is Markdown with YAML metadata for language, version, revision, provenance, and tags, and its fetch model supports incremental retrieval of reference files. 3. **[fact]** RAG-based API discovery systems solve scale and freshness by searching large corpora at inference time. Gorilla adapts to test-time document changes, ToolBench indexes 16,464 real-world REST APIs, and REST-GPT plans against OAS-described APIs using planner-selector-executor decomposition. 4. **[fact]** MCP solves interoperable runtime exposure, not broad discovery. After a connection is established, clients can negotiate capabilities, list tools/resources/prompts, and invoke them through structured schemas and typed results. 5. **[fact]** OAS is the common substrate that links these families. It is explicitly designed so humans and computers can discover and understand HTTP APIs, and it appears directly in RestGPT and AWS Bedrock action groups while remaining compatible with curation or retrieval workflows. 6. **[inference]** The right comparison is therefore not `context-hub` versus RAG versus MCP as direct substitutes. The three approaches intervene at different stages: prompt-time grounding, inference-time selection, and runtime invocation. 7. **[inference]** The approaches are complementary in deployment. A production stack can curate a small set of high-value APIs in a context hub, use retrieval over a long-tail catalogue for discovery, and invoke the selected capability through MCP or a similar protocol surface. 8. **[inference]** The main unsolved gaps across all three approaches are internet-scale server discovery and trust, delegated authentication and permissioning, end-to-end API drift management, and cost-aware cross-API orchestration. **Evidence map:** | Claim | Source | Confidence | Notes | |---|---|---|---| | [fact] `context-hub` exists to reduce API hallucination and session-forgetting | `https://raw.githubusercontent.com/andrewyng/context-hub/main/README.md` | high | Problem statement is explicit in the repository README | | [fact] `context-hub` entries are versioned Markdown docs with YAML metadata and incremental fetch | `https://raw.githubusercontent.com/andrewyng/context-hub/main/docs/content-guide.md`; `https://raw.githubusercontent.com/andrewyng/context-hub/main/docs/cli-reference.md` | high | Primary documentation of the data model and fetch model | | [fact] Gorilla uses a retriever to adapt to document changes and mitigate hallucinated API use | `https://arxiv.org/abs/2305.15334` | high | Primary paper abstract states both claims directly | | [fact] ToolBench covers 16,464 REST APIs from 49 categories and pairs ToolLLaMA with a neural API retriever | `https://arxiv.org/abs/2307.16789` | high | Primary paper provides the dataset size and retriever design | | [fact] REST-GPT plans and executes against OAS-described APIs with planner-selector-executor structure | `https://arxiv.org/abs/2306.06624`; `https://restgpt.github.io/` | high | Primary paper and project page agree | | [fact] MCP exposes tools/resources/prompts through negotiated capabilities and list/call style requests | `https://modelcontextprotocol.io/specification/latest/basic/lifecycle`; `https://modelcontextprotocol.io/specification/latest/server/tools`; `https://modelcontextprotocol.io/specification/latest/server/resources`; `https://modelcontextprotocol.io/specification/latest/server/prompts` | high | Core protocol text is definitive | | [fact] OAS is meant to let humans and computers discover and understand HTTP APIs | `https://swagger.io/specification/` | high | Direct definition from the specification | | [inference] The three approaches correspond to prompt-time grounding, inference-time selection, and runtime invocation | `https://raw.githubusercontent.com/andrewyng/context-hub/main/README.md`; `https://arxiv.org/abs/2307.16789`; `https://modelcontextprotocol.io/specification/latest/server/tools` | high | Inference is well supported by the different artefacts each system standardises | | [inference] None of the three fully solves global server discovery, trust, delegated auth, drift, or cost-aware orchestration | `https://arxiv.org/abs/2304.08244`; `https://modelcontextprotocol.io/specification/latest/server/tools`; `https://modelcontextprotocol.io/specification/latest/server/resources` | medium | Strongly supported by absence and by explicit residual challenges, but still a synthesis-level claim | **Assumptions:** - **[assumption]** Public `context-hub` design documents are representative of how the broader "context hub" pattern is currently being advanced. **Justification:** The repository is the named exemplar in the prompt, and no competing public specification with materially different goals surfaced in source review. - **[assumption]** The lack of a standard global MCP server directory in the consulted specification pages means discovery remains out-of-band in practice. **Justification:** The protocol defines initialization and per-server capability listing, but no consulted page defines internet-scale server-discovery semantics. **Analysis:** - **[inference]** `context-hub` and RAG both try to reduce wrong API usage, but they do so with opposite economic assumptions: curation spends more human effort up front to reduce model uncertainty later, while RAG spends more compute and retrieval complexity at runtime to cover a broader long tail. - **[inference]** MCP sits orthogonally to that trade-off because it does not answer "which API should I use?" by itself. It answers "once I know which server I trust, how do I discover and call its capabilities in a standard way?" - **[inference]** OAS is the hidden common denominator. It keeps reappearing because structured API semantics remain useful whether the system is curating docs, retrieving them, or compiling them into a runtime tool surface. **Risks, gaps, uncertainties:** - **[fact]** The OpenAI function-calling documentation in the source list was inaccessible from this environment due to `403` responses, so no claims here rely on it. - **[inference]** The current public state of the MCP ecosystem is evolving quickly, so client-support breadth may change faster than academic tool-use literature. - **[inference]** The boundary between "context hub" and "retrieval system" may blur if future systems auto-generate curated docs from OAS or expose a context hub itself through MCP. **Open questions:** - **[inference]** Will the ecosystem standardise a trusted registry layer for MCP servers, or will discovery remain client-specific and marketplace-specific? - **[inference]** Can OAS-to-context-hub pipelines generate high-quality agent-readable docs automatically, or is human curation the real source of the quality advantage? - **[inference]** What is the right evaluation benchmark for a layered system that combines curation, retrieval, and protocol-standardised invocation rather than testing those pieces separately? ### §7 Recursive Review - **[fact]** Coverage check: the investigation answers the `context-hub` problem statement and data model, the RAG landscape and representative systems, the MCP scope and discovery model, the main design axes, and the gap-analysis question. - **[fact]** Source check: every factual claim in the investigation maps to a directly consulted primary or repository-internal source, except the explicitly noted inaccessible OpenAI documentation, which is excluded from the evidence base. - **[fact]** Claim-labelling check: the investigation, reasoning, consistency check, depth expansion, and synthesis sections explicitly label claims as `[fact]`, `[inference]`, or `[assumption]`. - **[inference]** Final judgement: the evidence supports a layered-stack conclusion more strongly than a direct-competition conclusion, and no unresolved contradiction remains that would change the overall answer. --- ## Findings ### Executive Summary [inference] API context hubs, RAG-based API discovery, and MCP belong on one stack because they intervene at different points in the path from \"what tools exist\" to \"invoke this tool now.\" (Sources: `https://raw.githubusercontent.com/andrewyng/context-hub/main/README.md`; `https://arxiv.org/abs/2307.16789`; `https://modelcontextprotocol.io/specification/latest/server/tools`) [fact] Context hubs optimise repeated, high-trust workflows by packaging versioned, agent-oriented API guidance and preserving local notes that can be replayed on the next fetch. (Sources: `https://raw.githubusercontent.com/andrewyng/context-hub/main/README.md`; `https://raw.githubusercontent.com/andrewyng/context-hub/main/docs/feedback-and-annotations.md`) [fact] Retrieval-heavy systems optimise breadth and freshness by searching larger API corpora at inference time, which improves long-tail coverage but introduces retriever and planner failure modes that curated hubs largely avoid. (Sources: `https://arxiv.org/abs/2305.15334`; `https://arxiv.org/abs/2307.16789`; `https://arxiv.org/abs/2304.08244`) [fact] MCP optimises connected-server interoperability by standardising capability negotiation and tool, resource, and prompt exchange, while leaving server selection and trust establishment outside the protocol boundary. (Sources: `https://modelcontextprotocol.io/specification/latest/basic/lifecycle`; `https://modelcontextprotocol.io/specification/latest/server/tools`; `https://modelcontextprotocol.io/specification/latest/server/resources`; `https://modelcontextprotocol.io/specification/latest/server/prompts`) [inference] OAS is the recurring connective tissue across the field, and the durable gaps after all three approaches are still trust, delegated auth, version drift, and multi-system orchestration. (Sources: `https://swagger.io/specification/`; `https://restgpt.github.io/`; `https://docs.aws.amazon.com/bedrock/latest/userguide/agents-action-add.html`; `https://arxiv.org/abs/2304.08244`; `https://modelcontextprotocol.io/specification/latest/server/tools`) ### Key Findings 1. [fact] `context-hub` solves a narrow but practical problem by reducing hallucinated API usage and session-forgetting through curated, versioned documentation, persistent local annotations, and maintainer feedback loops that improve future agent runs. (Sources: `https://raw.githubusercontent.com/andrewyng/context-hub/main/README.md`; `https://raw.githubusercontent.com/andrewyng/context-hub/main/docs/feedback-and-annotations.md`) [confidence: high] 2. [fact] `context-hub` is a documentation registry rather than a runtime protocol, because its core data model is Markdown plus YAML metadata for language, version, revision, provenance, and tags, and its fetch model supports incremental retrieval of reference files. (Sources: `https://raw.githubusercontent.com/andrewyng/context-hub/main/docs/content-guide.md`; `https://raw.githubusercontent.com/andrewyng/context-hub/main/docs/cli-reference.md`) [confidence: high] 3. [fact] RAG-based API discovery systems solve scale and freshness by searching large corpora at inference time, with Gorilla adapting to test-time document changes, ToolBench indexing 16,464 real-world REST APIs, and REST-GPT planning against OAS-described APIs through planner-selector-executor decomposition. (Sources: `https://arxiv.org/abs/2305.15334`; `https://arxiv.org/abs/2307.16789`; `https://arxiv.org/abs/2306.06624`; `https://restgpt.github.io/`) [confidence: high] 4. [fact] MCP solves interoperable runtime exposure after connection, because clients can negotiate capabilities, list tools, resources, and prompts, and invoke them through structured schemas and typed results, but MCP does not itself provide an internet-scale directory of which servers exist. (Sources: `https://modelcontextprotocol.io/specification/latest/basic/lifecycle`; `https://modelcontextprotocol.io/specification/latest/server/tools`; `https://modelcontextprotocol.io/specification/latest/server/resources`; `https://modelcontextprotocol.io/specification/latest/server/prompts`) [confidence: high] 5. [fact] OAS is the common substrate linking these families, because it is explicitly designed so humans and computers can discover and understand HTTP APIs and it appears directly in RestGPT and AWS Bedrock action groups while remaining compatible with curation and retrieval workflows. (Sources: `https://swagger.io/specification/`; `https://restgpt.github.io/`; `https://docs.aws.amazon.com/bedrock/latest/userguide/agents-action-add.html`) [confidence: high] 6. [inference] The comparison should not treat `context-hub`, RAG, and MCP as direct substitutes, because the three approaches intervene at different stages of the stack: prompt-time grounding, inference-time selection, and runtime invocation. (Sources: `https://raw.githubusercontent.com/andrewyng/context-hub/main/README.md`; `https://arxiv.org/abs/2307.16789`; `https://modelcontextprotocol.io/specification/latest/server/tools`) [confidence: high] 7. [inference] The approaches are complementary in deployment, because a production system can curate a small set of high-value APIs in a context hub, use retrieval over a long-tail catalogue for discovery, and invoke the selected capability through MCP or a similar protocol surface. (Sources: `https://raw.githubusercontent.com/andrewyng/context-hub/main/README.md`; `https://arxiv.org/abs/2307.16789`; `https://modelcontextprotocol.io/specification/latest/server/tools`) [confidence: medium] 8. [inference] The main unsolved gaps across all three approaches remain internet-scale server discovery and trust, delegated authentication and permissioning, end-to-end API drift management, and cost-aware cross-API orchestration across heterogeneous services. (Sources: `https://arxiv.org/abs/2304.08244`; `https://modelcontextprotocol.io/specification/latest/server/tools`; `https://modelcontextprotocol.io/specification/latest/server/resources`) [confidence: medium] ### Evidence Map | Claim | Source | Confidence | Notes | |---|---|---|---| | [fact] `context-hub` exists to reduce API hallucination and session-forgetting | `https://raw.githubusercontent.com/andrewyng/context-hub/main/README.md` | high | Problem statement is explicit in the repository README | | [fact] `context-hub` entries are versioned Markdown docs with YAML metadata and incremental fetch | `https://raw.githubusercontent.com/andrewyng/context-hub/main/docs/content-guide.md`; `https://raw.githubusercontent.com/andrewyng/context-hub/main/docs/cli-reference.md` | high | Primary documentation of the data model and fetch model | | [fact] Gorilla uses a retriever to adapt to document changes and mitigate hallucinated API use | `https://arxiv.org/abs/2305.15334` | high | Primary paper abstract states both claims directly | | [fact] ToolBench covers 16,464 REST APIs from 49 categories and pairs ToolLLaMA with a neural API retriever | `https://arxiv.org/abs/2307.16789` | high | Primary paper provides the dataset size and retriever design | | [fact] REST-GPT plans and executes against OAS-described APIs with planner-selector-executor structure | `https://arxiv.org/abs/2306.06624`; `https://restgpt.github.io/` | high | Primary paper and project page agree | | [fact] MCP exposes tools/resources/prompts through negotiated capabilities and list/call style requests | `https://modelcontextprotocol.io/specification/latest/basic/lifecycle`; `https://modelcontextprotocol.io/specification/latest/server/tools`; `https://modelcontextprotocol.io/specification/latest/server/resources`; `https://modelcontextprotocol.io/specification/latest/server/prompts` | high | Core protocol text is definitive | | [fact] OAS is meant to let humans and computers discover and understand HTTP APIs | `https://swagger.io/specification/` | high | Direct definition from the specification | | [inference] The approaches correspond to prompt-time grounding, inference-time selection, and runtime invocation | `https://raw.githubusercontent.com/andrewyng/context-hub/main/README.md`; `https://arxiv.org/abs/2307.16789`; `https://modelcontextprotocol.io/specification/latest/server/tools` | high | Inference is strongly supported by the different artefacts each system standardises | | [inference] None of the three fully solves global server discovery, trust, delegated auth, drift, or cost-aware orchestration | `https://arxiv.org/abs/2304.08244`; `https://modelcontextprotocol.io/specification/latest/server/tools`; `https://modelcontextprotocol.io/specification/latest/server/resources` | medium | Synthesis claim supported by explicit residual gaps and by what the standards do not cover | ### Assumptions - **Assumption:** Public `context-hub` design documents are representative of the broader "context hub" pattern. **Justification:** The repository is the named exemplar in the prompt, and no competing public specification with materially different goals surfaced in source review. - **Assumption:** The absence of a standard global MCP server directory in the consulted specification pages means discovery remains out-of-band in practice. **Justification:** The protocol defines initialization and per-server capability listing, but no consulted page defines internet-scale server-discovery semantics. ### Analysis - [inference] `context-hub` and RAG both target wrong API usage, but they make opposite trade-offs: `context-hub` spends more human curation effort up front so that the model sees a high-trust, compact document later, while RAG spends more runtime compute and evaluation effort so that the agent can cover a broader long tail of APIs and adapt to changing documents. (Sources: `https://raw.githubusercontent.com/andrewyng/context-hub/main/README.md`; `https://arxiv.org/abs/2305.15334`; `https://arxiv.org/abs/2307.16789`) - [inference] MCP sits orthogonally to that trade-off because it does not answer "which API should the agent choose?" by itself; it answers "once the client trusts a server, how can the client discover and invoke its capabilities through one standard protocol?" (Sources: `https://modelcontextprotocol.io/specification/latest/basic/lifecycle`; `https://modelcontextprotocol.io/specification/latest/server/tools`) - [inference] OAS is the hidden common denominator across the field because structured API semantics remain valuable whether a system is curating docs, retrieving them at inference time, or compiling them into a runtime tool surface. (Sources: `https://swagger.io/specification/`; `https://restgpt.github.io/`; `https://docs.aws.amazon.com/bedrock/latest/userguide/agents-action-add.html`) ### Risks, Gaps, and Uncertainties - [fact] The OpenAI function-calling documentation in the source list was inaccessible from this environment due to `403` responses, so no claims here rely on it. (Source: failed fetch of `https://platform.openai.com/docs/guides/function-calling`) - [inference] MCP client support is evolving quickly, so ecosystem breadth may change faster than the academic literature that grounds the RAG comparison. (Sources: `https://modelcontextprotocol.io/clients`; `https://arxiv.org/abs/2305.15334`; `https://arxiv.org/abs/2307.16789`) - [inference] The boundary between "context hub" and "retrieval system" may blur if future systems auto-generate curated docs from OAS or expose a context hub itself through MCP. (Sources: `https://swagger.io/specification/`; `https://modelcontextprotocol.io/specification/latest/server/tools`; `https://raw.githubusercontent.com/andrewyng/context-hub/main/docs/content-guide.md`) ### Open Questions - [inference] Will the ecosystem standardise a trusted registry layer for MCP servers, or will discovery remain client-specific and marketplace-specific? - [inference] Can OAS-to-context-hub pipelines generate high-quality agent-readable docs automatically, or is human curation the real source of the quality advantage? - [inference] What is the right benchmark for a layered system that combines curation, retrieval, and protocol-standardised invocation rather than testing those pieces separately? --- ## Output - Type: knowledge - Description: Comparative research on how agents discover and use external APIs across curated context hubs, large-scale retrieval systems, and runtime interoperability protocols, with a layered-stack conclusion rather than a winner-take-all conclusion. - Links: - https://raw.githubusercontent.com/andrewyng/context-hub/main/README.md - https://modelcontextprotocol.io/specification/latest/server/tools - https://arxiv.org/abs/2307.16789