Show HN: Context Plugins – API context for AI coding assistants

[sohaibtariq]

Hi, we're Sohaib and Hannan from APIMatic.

We built Context Plugins: given an OpenAPI spec, we generate SDKs and an MCP server that exposes structured API context to AI coding assistants.

This gives tools like Cursor access to comprehensive, up-to-date API context (including SDK documentation and API integration patterns), instead of relying on outdated training data or code scraped from GitHub.

We've just launched a pilot with PayPal, it's live on the PayPal Developer Portal https://developer.paypal.com/serversdk/java/getting-started/....

In our benchmarks for the PayPal API, Cursor generated integration code 2x faster with 65% lower token usage compared to baseline Cursor without the plugin.

The problem we kept seeing was AI coding assistants generating incorrect API integration code. We asked Cursor to integrate the PayPal API into an e-commerce application across multiple runs:

- 13% of runs pulled in a deprecated SDK.

- 87% generated HTTP calls based on deprecated documentation.

API providers maintain API and SDK docs, but AI assistants don’t always use them. They use a combination of web search, training data and hallucinations to write API integration code.

As a result, developers end up debugging and rewriting AI-generated code.

We've been generating SDKs from API specs for 10+ years at APIMatic. When AI coding assistants started generating the exact kind of broken integration code we'd spent a decade fixing, we asked: what if we could take our code generation pipeline and add AI context generation to it?

MCP gave us the transport layer. Our API spec parsing and SDK generation engine gave us the context. The combination meant we could deliver deterministic API context, derived from the canonical spec, directly into the developer's IDE.

Here's how it works:

1. An API provider uploads their OpenAPI spec to APIMatic.

2. We generate and publish high quality SDKs in multiple languages.

3. We generate an MCP server containing tools and prompts that expose language-specific SDK context, optimized for LLMs.

4. Developers wanting to integrate with the API install the MCP server in Cursor, Claude Code, or GitHub Copilot.

When a developer asks to integrate auth, the coding assistant queries the MCP server, retrieves the required context (auth flows, integration patterns, latest SDK version, SDK interfaces etc.), and generates code using the official SDK.

Getting started:

- We've published Context Plugins for ten APIs. The URL in this post takes you to our public showcase, which is the quickest way to try them out without signing up.

- If you want to generate Context Plugins from your own API, you can sign up for a free trial on the APIMatic website (2-week all-access trial, no credit card required).

Feedback:

We'd love for you to try out Context Plugins and give us your feedback and suggestions. Two questions for the HN community:

- What's the worst AI-generated API integration bug you've encountered? We're collecting failure patterns to improve our context coverage.

- What context do you think coding assistants need to generate accurate API integration code, in addition to API or SDK contracts?

[VitalStack]

The pattern of serving authoritative domain context via MCP rather than relying on model training data generalizes well beyond API specs. We've seen the same dynamic building a supplement-drug interaction MCP at VitalStack: once an AI assistant can query a structured interaction database rather than approximate from training data, the failure mode shifts from confident hallucination to an explicit "no data found for this combination." One question on the implementation: when an API provider ships a breaking change, what's the latency between that release and the Context Plugin updating its served specification—and is there a signal to the AI that the context may be stale?

[sohaibtariq]

Good question. In our case, Context Plugins are not maintained as a separate context layer that can drift from the rest of the API surface.

APIMatic offers an entire Developer Experience Platform where everything is generated from the same API spec. We already generate SDKs, API portals and API Copilots from that source. Context Plugins are another artefact generated from that same pipeline.

That means when an API provider updates their spec and runs their release pipeline, the SDKs, docs, and Context Plugins all update together. So in practice, there’s virtually no lag between a release and the context reflecting that release, because they’re all produced from the same source at the same time.

On the stale context question, there’s also a useful signal there. If a developer has an older SDK version installed and starts a new session after a newer release is available, the Context Plugin can see both the installed SDK version and the latest published version. So it can surface that a newer SDK version exists.

That sync is a big part of the value for us. The goal is to keep docs, SDKs, and AI-facing context aligned so developers and AI assistants always have up-to-date information about an API, without adding maintenance overhead for API teams.

[linsys]

This is what we do for our own internal apps, what we do is actually much more complex we ingest all the docs from Github and Confluence AND we generate code-maps into a RAG then we expose it with an MCP, integrate that MCP into claude code so claude can ask for both our coding standards, IaC standards, testing standards, etc.. but also has the full context about the applications it needs to consume from or deliver to.

[sohaibtariq]

Very cool.

If we want AI assistants to contribute to a codebase like a productive member of the team, they need the same kind of context you’d give a new hire. Coding standards, infra conventions, testing patterns, and the shape of the system all matter.

We’re focused on a narrower version of that same problem.

First, we want to make it simple for any team to adopt a new library or SDK without reading a pile of docs or spending hours writing and debugging integration code. The goal is to make it easy for an agentic coding workflow to absorb a new API library quickly and use it correctly.

Second, a lot of teams are already maintaining their own AI context across AGENTS.md files, skills, and MCP servers. That means API providers, and really maintainers of any library at this point, need to provide a context layer that fits into what teams have already built. Adding a new dependency shouldn’t force every team to create and maintain a separate context layer just to consume that API well.

That’s the part we care about a lot: SDK context should be generated and maintained automatically, stay in sync with the SDK and docs, and avoid becoming extra work for either the API provider or the API consumer.

[zensorsolutions]

This is interesting — especially the focus on reducing incorrect outputs rather than just improving generation.

Feels like a common pattern across AI tools right now: getting something generated is easy, getting something reliable enough to act on is the hard part.

Have you noticed whether developers trust the output more when the source of context is explicit (like SDKs), vs inferred?

[sohaibtariq]

From our benchmarks and internal tests, we’ve noticed a few trust signals developers look for.

The first is simply what the model appears to be grounding on. If it’s pulling up SDK method names and library docs, developers feel much better about the result than when it looks like the model is piecing things together from web search, blogs, GitHub snippets, or other unofficial sources.

We’ve also found that even among authoritative sources, there’s a real difference between an OpenAPI spec or API reference, and SDK documentation. An OpenAPI spec or API reference is authoritative, but it still leaves the model with a lot to figure out. It has to infer how to authenticate, how to handle pagination, what to do in case of errors/failure, and then turn all of that into working code in the right place in an existing app.

That’s a long chain of inference, and every extra step is another place where things can go wrong.

SDK context cuts out a lot of that. Much of the complexity is already wrapped in the library, so the model is usually figuring out which SDK method to call and how to wire it up, instead of inventing the integration from scratch.

In practice, the biggest trust builder is the outcome: does the generated code run on the first try?

That’s the outcome developers care about most, and it’s the pattern we saw in our user tests. Context Plugins help get much closer to that outcome.

We’ve published a case study that goes deeper into the numbers here: https://www.apimatic.io/product/context-plugins/case-study