API teams lack common tooling and guidance to deliver MCP servers alongside their existing APIs for copilot integration.

Teams are independently adopting 3rd-party MCP servers without a governed approach to discovery, onboarding, and authentication.

Security teams must evaluate and approve MCP server usage within developer IDEs before enterprise-wide adoption can proceed.

HTTP streaming and SSE connections required by MCP and AI services conflict with existing corporate security policies and infrastructure.

Organizations need to understand how MCP fits into existing API infrastructure and governance tooling they have invested in over the past decade.

Traditional filter-based catalog search doesn't match how developers think about their problems, leading to duplicate API development.

API documentation and metadata quality must improve so that both developers and AI agents can effectively discover and use internal APIs.

MCP servers that combine multiple APIs into business-oriented capabilities need a standard way to be described and governed.

The assumption that AI will figure out how to use MCP servers is wrong, and traditional documentation and discovery are still required.

Multiple teams are independently building MCP integrations for the same third-party services without coordination or visibility.

Building an accurate catalog of APIs and services requires automated discovery rather than manual registration that developers resist.

Governance rules need to be available directly in developers' coding assistants and AI agents, not just in standalone tools and pipelines.

Nico discovered that MCP servers built from existing API documentation fail because the docs were written for humans, not AI agents.

Nico sees MCP servers exposing every API option when agents only need task-specific subsets, wasting context and causing confusion.

Developer documentation sites must be rebuilt to enable AI agents to efficiently consume them, including markdown endpoints for full content access.

Context engineers need to evaluate whether AI agents called APIs correctly—with right parameters, in right order—not just whether the final output looks correct.

Context engineers need to consolidate many upstream APIs and MCP servers into a smaller set of efficient tools that agents can use effectively.

MCP-enabled documentation disproportionately benefits experienced developers because junior developers don't know what questions to ask.

Developers need to understand how an API behaves in production, but most documentation remains reference-only.

Documentation efforts are treated as a publishing exercise rather than a product discipline that actively enables and teaches developers.

MCP-enabled documentation should accelerate implementation work inside IDEs and copilots, but 'ask anything' interfaces fail when users don't know the right prompts.

The repo context layer (README, CONTRIBUTING, AGENTS) has no clear owner as AI copilots roll out across IDEs.

Markdown docs must follow predictable, machine-reliable structures so agents can consistently locate authoritative answers.

Organizations need knowledge graphs and semantic layers to give AI agents structured, contextual understanding of API relationships, business logic, and entity models — not just flat catalogs.

API teams need to adopt context engineering as a discipline — curating the optimal set of instructions, knowledge, and feedback that enables agents to effectively discover, understand, and consume APIs.

Traditional API response formats like JSON and XML aren't optimized for AI agent consumption — organizations need data formats and response structures that minimize token usage while maximizing agent comprehension.

Enterprises need an internal registry of approved MCP servers that surfaces inside the developer IDE, acting as an allow-list so developers discover only vetted servers.

The MCP discovery registry (which servers are approved) and the package registry (where the binary actually lives) are two different systems with different governance requirements.

Iris finds that EHRs are deliberately disease-agnostic, so the right information is rarely captured at the first patient encounter — sending patients on multi-month detours through the wrong specialists. She needs disease-specific information models that scaffold what to capture and when.

Enterprises with mature OpenAPI portal pipelines need MCP-server documentation that flows through the same build process — not vendor-coupled extensions or a parallel doc system.