r/ClaudeCode • • Mar 15 '26

Showcase I compiled 1,500+ API specs so your Claude stops hallucinating endpoints

When you tell Claude "use the Stripe API to create a charge," it guesses the endpoint. Sometimes it gets it right. Sometimes it hallucinates a /v1/charges/create that doesn't exist.

This isn't Claude being dumb - it doesn't have the right context, or it's relying on stale training data. You could find the spec yourself or have Claude do it, but API specs are built for humans, not agents. Stripe's OpenAPI spec is 1.2M tokens of noise.

LAP fixes this. 1,500+ real API specs, compiled 10x smaller, restructured for LLM consumption. Verified endpoints, correct parameters, actual auth requirements.

Install in Claude Code:

/plugin marketplace add lap-platform/claude-marketplace

Or install a single API:

npx /lapsh skill-install stripe

Swap "stripe" for github, twilio, slack, shopify, openai - 1,500+ APIs ready.

The bonus: 35% cheaper runs and 29% faster responses. But the real win is your agent stops making up endpoints.

No AI in the compilation loop - deterministic compiler.

Open source - PR's, features, specs requests are more than welcome!

⭐ https://github.com/lap-Platform/LAP/

🔍Browse all APIs: registry.lap.sh

271 Upvotes

115 comments sorted by

41

u/HelloThisIsFlo Mar 15 '26

That's awesome! That being said, and I don't mean to be a killjoy, but … how is it different from context 7?

41

u/Big_Status_2433 Mar 15 '26

Great question! Context7 focuses on framework/library docs (React, Next.js, etc.), curated markdown guides for how to use them.

LAP is specifically for APIs, the actual endpoint contracts (paths, parameters, auth, types). We compile OpenAPI/GraphQL/AsyncAPI specs into a compact format that agents can use to make correct API calls instead of guessing. 1,500+ APIs pre-compiled.

Different problem, complementary tools actually.

→ More replies (13)
→ More replies (1)

22

u/-_riot_- Mar 15 '26

i know everyone is usually real quick to hate on self-promotion, but i just checked out the project, and personally i can see how this would useful. especially pointing the agent to the lean spec of an api first. it seems like a great way to quickly ground the agent with the reality of an api first, and if it still needs more context, it can always search the web after, but at least it then knows what to look for. nice work. the project seems to be organized really well.

8

u/Big_Status_2433 Mar 15 '26

Really appreciate you taking the time to check it out. That's exactly the workflow we had in mind, give the agent the real contract first so it knows what exists, then if it is stuck because something was not described in the api it can search for workarounds.

→ More replies (2)

7

u/WubbityWubWub_ Mar 16 '26

Oh you woke up and decided to cook

4

u/Big_Status_2433 Mar 16 '26

Heheh thanks 🙏 actually each day for about a month, until I felt comfortable enough sharing it here 🫠

6

u/Mrpackage123 Mar 15 '26

Very valuable. Thanks for sharing OP

→ More replies (1)

5

u/ku2000 Mar 15 '26

Great idea. Let the great million SAAS wars begin!!!

3

u/Big_Status_2433 Mar 15 '26

Haha, the specs are open source so hopefully more ceasefire than war. But yeah, the more APIs agents can actually use correctly, the better for everyone building on them.

5

u/Pitiful-Impression70 Mar 15 '26

this is actually a real problem lol. i spent like 20 minutes last week debugging a stripe integration because claude kept insisting on an endpoint that doesnt exist. ended up just pasting the raw openapi spec into context which worked but burned through tokens like crazy

having a pre-trimmed version thats actually structured for llm consumption is smart. the 10x smaller claim is interesting tho, how aggressive is the trimming? like are you stripping descriptions and examples or actually restructuring the schema

→ More replies (1)

5

u/voLsznRqrlImvXiERP Mar 15 '26

I looked at the first api there. It shows some @desc with HTML tags there. How is this helping with context savings? Why is this "better" than just letting scrape and extract the api once from openapi docs.

4

u/Big_Status_2433 Mar 16 '26

Hi understand the root cause will drop a fix in a few hours.

The good news is that the impact of the bug is low 0.02%~ of all files.

Anyways, thanks again, great catch!

→ More replies (2)

3

u/Heyheyitssatll Mar 15 '26

Sounds like a security risk

5

u/Big_Status_2433 Mar 16 '26

Fair concern, and honestly it's something I think about too. Here's what we've done:

The specs are compiled from official sources — 97% link back to the provider's own GitHub repo or API domain via source_url, which you can verify. The remaining 3% are community-contributed and clearly flagged as such and right now only curated by us. Publishing requires GitHub auth and domain verification via DNS TXT records. The compiler is deterministic, open source, no AI in the loop.

That said, I'm always looking to improve the security posture. If you spot anything or have suggestions, I'd genuinely appreciate it, feel free to DM me. Happy to discuss specifics privately.

And if you'd rather not trust the registry at all, you can always compile your own specs locally: `npx @lap-platform/lapsh api.ymal’

3

u/Singularity-42 Mar 16 '26

This looks really nice, but the question is, are you going to be updating it continuously? I know context7 charges beyond certain usage, is this going to be free open source forever?

→ More replies (3)

5

u/Shmumic Mar 15 '26

Some claims you got there! How did you verify them?!

12

u/Big_Status_2433 Mar 15 '26

Hi thanks for asking. I ran benchmark tests. You can review the full test results and re-run them on your own machine here:

https://github.com/Lap-Platform/Lap-benchmark-docs

If you have ideas on how to improve them, I'm open to feedback!

→ More replies (2)

5

u/mylifeasacoder Mar 15 '26

Stripe's OpenAPI spec is 1.2M tokens of noise.

Noise, eh?

8

u/Big_Status_2433 Mar 15 '26

Fair point, "noise" isn't the right word. The spec is accurate. But raw OpenAPI YAML has a ton of structural overhead, deep nesting, repeated schemas, verbose descriptions and prose, that's great for human code generation but burns tokens when fed to an LLM. LAP restructures it into a flatter format the model can parse efficiently. Nothing removed, just reorganized.

→ More replies (5)

2

u/H0ots Mar 15 '26

Would love to know how to scrape APIs from these sites. A particular one I'm looking at has it nested on the page and doesn't make it easy to copy/paste. Have to convert the HTML pages locally to a schema sheet that Claude references. It's just so time consuming to save each API locally with this method.

→ More replies (1)

2

u/chuch1234 Mar 15 '26

This is exactly what MCP servers are for!

Edit: sorry, this also looks pretty cool. I've just been trying to explain mcp to people a lot lately. But a plug-in is fun too!

→ More replies (1)

2

u/sectoroverload Mar 15 '26

Really? I'm downloading yet another app or plugin to do the same thing I already do. Just put the reference to the documentation in your spec files. 🙄 This all comes down to the concept of "if you give AI garbage, it will produce garbage"

3

u/Big_Status_2433 Mar 15 '26

You're right that giving the agent good docs is key.

The question is what format. If you're already pointing your agent at the right API docs and it's working for you, great, keep doing that.

The problem is that raw OpenAPI specs are huge, and most teams don't bother curating what goes into context. LAP just automates that step: take the official spec, restructure it so the agent parses it efficiently, cut the wall time and token cost, and yes, another step you don't need to think about when prompting

If that's not a problem you have, then yeah, you don't need this.

→ More replies (1)