HN Explorer

Launch HN: Strata (YC P25) – One MCP server for AI to handle thousands of tools

133 points by wirehack ↗ HN
Hey HN! We are Klavis AI (https://www.klavis.ai/) and we're launching Strata, one open-source MCP server that helps AI agents use thousands of API tools without getting overwhelmed. Instead of showing all available tools at once, Strata reveals them step-by-step based on what the AI actually needs.

As a former Senior SWE on Google Gemini 's tool use team, I saw firsthand how AI would struggle with tools. If you've built AI agents, you've likely hit the same walls: (1) AI agents struggle to pick the right API from hundreds of options. (2) Tool descriptions and info consume massive token budgets. (3) Most servers cap at 40~50 tools to avoid these problems, limiting what you can build.

Instead of flooding the AI with everything upfront, Strata works like a human would. It guides the AI agents to discover relevant categories, then lists available actions in those categories. It relies on LLMs’ reasoning to drill down progressively to find the exact tool needed. Here are some examples:

Github query: "Find my stale pull requests in our main repo"

Strata: AI model identifies GitHub → Shows categories (Repos, Issues, PRs, Actions) → AI selects PRs → Shows PR-specific actions -> AI selects list_pull_requests → Shows list_pull_requests details -> Executes list_pull_requests with the right parameters.

Jira query: "Create a bug ticket in the 'MOBILE' project about the app crashing on startup."

Strata: AI identifies Jira → Shows categories (Projects, Issues, Sprints) → AI selects Issues → Shows actions (create_issue, get_issue) → AI selects create_issue → Shows create_issue details → Executes with correct parameters.

Slack query: "Post a message in the #announcements channel that bonus will be paid out next Friday."

Strata: AI identifies Slack → Shows categories (Channels, Messages, Users) → AI selects Messages → Shows actions (send_message, schedule_message) → AI selects send_message → Shows send_message details → Executes with correct parameters.

This progressive approach unlocks a huge advantage: depth. While most integrations offer a handful of high-level tools, Strata can expose hundreds of granular features for a single app like GitHub, Jira, etc. Your AI agent can finally access the deep, specific features that real workflows require, without getting lost in a sea of options.

Under the hood, Strata manages authentication tokens and includes a built-in search tool for the agent to dig into documentation if it gets stuck.

On the MCPMark https://mcpmark.ai/leaderboard/mcp, Strata achieves +15.2% higher pass@1 rate vs the official GitHub server and +13.4% higher pass@1 rate vs the official Notion server. In human eval tests, it hits 83%+ accuracy on complex, real-world multi-app workflows.

Here is a quick demo to watch Strata navigate a complex workflow with multiple apps, automatically selecting the right tools at each step: https://www.youtube.com/watch?v=N00cY9Ov_fM.

You can connect to any external MCP Server into Strata, and we have an open source version for it: https://github.com/Klavis-AI/klavis.

For team or production use with more features, visit our website: https://www.klavis.ai. Add Strata to Cursor, VS Code or any MCP-compatible application with one click. You can also use our API to easily plug in Strata to your AI application.

We look forward to your comments. Thanks for reading!

25 comments

[ 213 ms ] story [ 1779 ms ] thread
[deleted]
(comment deleted)
bigolnik
How does this differ from something like nexusrouter?
justchad
This looks very relevant and useful to what I'm working on at the moment. The LLM gets lost in all of the tools we provide for certain actions.
CuriouslyC
This is something I actually started to work on and put down because it wasn't exciting enough, but it's a legit product that fills a niche and congrats on the launch.

The biggest issue I found was getting agents to intelligently navigate the choose your own adventure of searching for the right tool. It amazes me that they're so good at coding when they're so bad at tool use in general. I'm sure your MCP responses were a fun bit of prompt engineering.

ssgodderidge
Is the goal to make a “universal MCP” that makes it easy to let MCP clients execute thousands of tools on a session by session basis? Or is it more focused on initial tool discovery and registration? If it’s the former, does the process add more latency between user taking action and tool getting executed?
tleyden5iwx
Looks really useful! Do you happen to have a gallery of apps using it? In particular, I'd like to see how desktop or mobile apps handle the oauth flows.
nycdatasci
The attack surface for agents with MCP access grows exponentially with the number of tools. On the scale of thousands of tools, I think it's nearly impossible to understand potential interactions and risk. Do you have any innovative controls in place that would help a CISO get comfortable with a product like this in an enterprise context?
typpilol
Comparing to the official GitHub server isn't a good benchmark because it's a bloated mess of tools still.
darkbatman
We kinda use https://github.com/googleapis/genai-toolbox but for databases looking forward if klavis provide more or general solution.

Ideally when we are writing agents we need mcp to support auth, custom headers because by design when deploying for saas we need to pass around client params to be able to isolate client connections.

We do token optimisation and other smart stuff to save token money. Looking forward to try this as well if this solves similar problems as well

koliber
How do you handle compliance questionnaires from companies that adhere to SOC2 guidelines? If I used Klavis how would I tell my clients which information I send to which external partners?
deepdarkforest
1. Interesting approach, but the pricing seems 1-2 orders of magnitude too expensive. For your example for slack, It contains 4 calls for an action. Pricing shows 100 dollars per 10k cals, so 1 cent per call. This means, for an agent that lets say does 4 actions, so and your examples show at least 3-4 api calls per action , it's already 12 cents? Similar tools like composio.dev have 200k calls for 29 dollars, so around 70x cheaper (both for the cheapest tier). Even with needing only 1 call for subsequent calls, 1 cent per single api call sounds wrong, at least for our use case it does not economic sense to pay 5-10 cents on top of llm costs on every user query. Apologies if I'm missing something!

2. Could this not be replicated by others by just handmaking a fuzzy search tool on the tools? I think this is the approach that will win, even with rag for lets say 10k plus tools maybe in the future, but not sure how much differentiation this is in the long term, i've made this search tool myself a couple of times already

progbits
The fact people are giving credentials to all these MCP tools keeps amazing me.

Ten years ago if you built a service that asked you for permissions to everything imaginable most people would keep well clear. I guess the closest was Beeper which wanted your social passwords but that was heavily criticized and never very popular.

Now you slap an AI label on it and you can't keep people away.

gk1
What do you propose they do? Because although something like Strata makes it easier, the reality is people are piling up MCP servers like they're free cupcakes. There's no getting the cat back in the box.

(I'm not in security so I genuinely don't know and am curious.)

smrtinsert
We're keeping an unofficial allow list at work. Basically just major software companies only. Third party mcp servers at this point are basically just attack vectors. How do you even vet them continuously?

Honestly vetting MCP seems like a YC company in and of itself.

electric_muse
MCP is like the "app store" for LLMs. LLMs can only do so much by themselves. They need connectivity to pull in context or take actions. Just like how your phone without apps is pretty limited in how useful it is.

Sure, teams could build their own connectors via function calling if they're running agents, but that only gets you so far. MCPs promise universal interoperability.

Some teams, like Block, are using MCP as a protocol but generally building their own servers.

But the vast majority are just sifting through the varying quality of published servers out there.

Those who are getting MCP to work are in the minority right now. Most just aren't doing it or aren't doing it well.

But there are plenty of companies racing into this space to make this work for enterprises / solve the problems you rightfully bring up.

As others have said here, the cat is out of the bag, and it is not going back in. MCP has enough buy-in from the community that it's likely to just get better vs. go away.

Source/Bias disclaimer: I pivoted my company to work on an MCP platform to smooth out those rough edges. We had been building integration technology for years. When a technology came along that promised "documentation + invocation" in-band over the protocol, I quickly saw that this could solve the pain of integration we had suffered for years. No more reading documentation and building integrations. The capability negotiation is built into the protocol.

Edit: a comma.

jfdi
Nice work this definitely feels like a market gap, for those who’ve been deep enough to experience it.
nextworddev
As an investor, I’m hesistant to invest in mcp infra startups
technocrat8080
How do you folks think about the Manus finding on dynamic tool selection? https://manus.im/blog/Context-Engineering-for-AI-Agents-Less...

> A natural reaction is to design a dynamic action space—perhaps loading tools on demand using something RAG-like. We tried that in Manus too. But our experiments suggest a clear rule: unless absolutely necessary, avoid dynamically adding or removing tools mid-iteration. There are two main reasons for this:

> 1. In most LLMs, tool definitions live near the front of the context after serialization, typically before or after the system prompt. So any change will invalidate the KV-cache for all subsequent actions and observations.

> 2. When previous actions and observations still refer to tools that are no longer defined in the current context, the model gets confused. Without constrained decoding, this often leads to schema violations or hallucinated actions.

> To solve this while still improving action selection, Manus uses a context-aware state machine to manage tool availability. Rather than removing tools, it masks the token logits during decoding to prevent (or enforce) the selection of certain actions based on the current context.

alooPotato
Can services dd to your supported list of MCP servers? Or do you write all the servers?
carloscheddar
"One MCP server for AI to handle thousands of tools" I wonder if they intended to refer the Tron movie where the Master Control Program(MCP) handles thousands of programs.
rooftopzen
Dove deep into this - 25+ security issues; no thx
adv0r
I always dreamed of a bidding protocol for tools...
saberience
This is a solution seeking a problem. Why would we want a single reliable agent to have access to 1000s of tools? When would this ACTUALLY be valuable or useful.

What IS useful and offers value is having an agent which accesses 1 or 2 tools but always uses those tools accurately and correctly 99.9+% of the time.

I've seen tons of MCP companies who are offering 1000s of wrapped HTTP APIs as MCP tools, which is note very easy to implement, but in reality, it's totally fucking useless for enterprise use-cases which need to work reliably, in a secure, repeatable fashion.

Any chump can rig an MCP client to 20 tools, but then watch your agent fail again and again and again.

Basically, this is a bad idea for a business and I'd personally suggest pivoting to something that focuses on ensuring a single agent works reliably, provides guardrails, evaluation, security etc. This is the real challenge to solve.