Application Programming Interface (API) Context Hubs, Retrieval-Augmented…

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?

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: raw.githubusercontent.com; arxiv.org/abs/2307.16789; modelcontextprotocol.io)

[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: raw.githubusercontent.com; raw.githubusercontent.com)

[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: arxiv.org/abs/2305.15334; arxiv.org/abs/2307.16789; 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: modelcontextprotocol.io; modelcontextprotocol.io; modelcontextprotocol.io; modelcontextprotocol.io)

[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: OpenAPI Specification; restgpt.github.io; docs.aws.amazon.com; arxiv.org/abs/2304.08244; modelcontextprotocol.io)

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: raw.githubusercontent.com; raw.githubusercontent.com) [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: raw.githubusercontent.com; raw.githubusercontent.com) [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: arxiv.org/abs/2305.15334; arxiv.org/abs/2307.16789; arxiv.org/abs/2306.06624; 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: modelcontextprotocol.io; modelcontextprotocol.io; modelcontextprotocol.io; modelcontextprotocol.io) [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: OpenAPI Specification; restgpt.github.io; docs.aws.amazon.com) [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: raw.githubusercontent.com; arxiv.org/abs/2307.16789; modelcontextprotocol.io) [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: raw.githubusercontent.com; arxiv.org/abs/2307.16789; modelcontextprotocol.io) [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: arxiv.org/abs/2304.08244; modelcontextprotocol.io; modelcontextprotocol.io) [confidence: medium]

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: raw.githubusercontent.com; arxiv.org/abs/2305.15334; 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: modelcontextprotocol.io; modelcontextprotocol.io)
• [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: OpenAPI Specification; restgpt.github.io; docs.aws.amazon.com)

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 OpenAI function calling / tool use documentation)
• [inference] MCP client support is evolving quickly, so ecosystem breadth may change faster than the academic literature that grounds the RAG comparison. (Sources: modelcontextprotocol.io; arxiv.org/abs/2305.15334; 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: OpenAPI Specification; modelcontextprotocol.io; raw.githubusercontent.com)

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?

sources

• [x] andrewyng/context-hub — repository README and linked documentation
• [x] Anthropic MCP specification — protocol overview and specification
• [ ] MCP GitHub organisation — 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 — the structured API description standard underlying most tool integration work
• [x] LangChain tools documentation — current tool and MCP adapter navigation
• [ ] OpenAI function calling / tool use documentation — 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