Launching today
AgentKey
One-stop live data marketplace for your agent
442 followers
One-stop live data marketplace for your agent
442 followers
AgentKey is a plugin that connects your agent to live external data in one command. Install it into Claude Code, Codex, OpenClaw, or any MCP-based agent and instantly unlock access to search, web pages, social platforms, finance, e-commerce, business and crypto data. No integrations. No setup. Auto failover keeps workflows running.
AgentKey
Hey the token math on tool discovery is honestly the most concrete detail in the whole pitch. Going from roughly 35,000 tokens to about 1,500 by training a retrieval layer instead of dumping every endpoint definition into context is a real architecture decision, not just a marketing line, and it's the kind of problem that quietly breaks a lot of MCP integrations once they scale past a handful of tools for sure.
But when the retrieval model picks the wrong endpoint for an ambiguous request, is that visible anywhere, or does a wrong pick just look like a silent bad result downstream?
AgentKey
@uddipta Silent wrong pick is exactly the failure mode that matters, so honest answer: the retrieval layer never executes anything on its own. It returns a shortlist of candidates with descriptions into the agent's context, the agent picks one, pulls the full schema for that tool, then calls it. Ambiguity usually shows up as a weird shortlist in the transcript, not a hidden wrong hop, and the agent can just re query with better phrasing. The remaining gap is real though: if the agent picks a plausible but wrong candidate, that does land as a bad result downstream. Today you'd trace it through the console call log. Surfacing the retrieval ranking itself is on the list, this thread has basically been writing our observability roadmap for us.
AgentKey
@uddipta Honest answer: right now a wrong pick mostly just looks like a normal result. Explicit errors are easy, the agent sees the failure and retries. Silent bad picks are the hard case and you put your finger on exactly where we're weakest.
The way we think about it, discovery is a loop: find the tool, judge it, call it, then feed the outcome back so the next pick is better. We have the first three. The feedback part is where the real work is, and it's barely started.
The thing that makes it tractable is that we sit in the middle of every call, so we can actually measure this. Which endpoints get picked for which phrasings, where results get thrown away or re-queried, which providers quietly underperform on ambiguous requests. None of that is exposed yet and honestly our own dashboards are thin. But that's the path: make the wrong picks visible in the data first, then drive the rate down.
Good question. Not many people get this far into it.
the social media data tier is the part I'd want more detail on - scraping platforms like X or LinkedIn directly usually runs into their ToS, and enforcement can hit the scraper's IP/account rather than the end user. when AgentKey serves social data, who's actually taking on that platform-side risk, is it abstracted away by using official APIs where available, or is it scraping under the hood and you're the one absorbing the ban risk
AgentKey
@galdayan We don't scrape under the hood. Social data comes from established vendors, some official APIs, some their own infrastructure, and managing that platform relationship is their core business. What we control is the user side, read-only access, no account linking, no credentials. Upstream enforcement lands upstream, not on you.
The auto failover is quietly the best part. One of the search providers had a bad day last month and my research pipeline didn't even notice.
AgentKey
@shirley_mou "didn't even notice" is exactly the bar we set for it. We track latency and error rates per provider and reroute before requests start failing, so if it's working right there's nothing to see. Glad it earned its keep quietly
AgentKey
@shirley_mou Ha, we saw that one. A provider went down for a few hours, traffic just moved over. That's exactly why we built it. Your agent shouldn't stop working because someone else is having a bad day. Good to hear it did its job.
honestly the auto failover part sounds super useful, would be great if there was a way to see which data source it switched to and why, like a quick log or notification. that way its easier to trust the results when something jumps from one provider to another.
AgentKey
@demet44834 Good call, and framing it as a trust thing is exactly right. Two pieces exist today, the console keeps a full log of every api call, and when a provider is having issues we flag it on the agentkey store page. What's missing is the part you're describing, a marker on the call itself saying it got rerouted and why. That's a genuinely good suggestion, adding it to the list.
AgentKey
@demet44834 Love this suggestion. The failover is one of those features you don't appreciate until something breaks. Seeing a small note like "rerouted from X due to timeout" would be great for transparency without getting in the way! Thank you Demet!
Half my agent demos used to die live because one upstream API picked that moment to have an outage. Failover should be table stakes and somehow nobody else ships it.
AgentKey
@jocky Yeah. When a tool breaks on you, you just go find another one. Agents never had that option. No way to discover what else is out there, no place to go looking. So they just die.
That's the gap we're filling. Glad your demos survive now.
@yanshuo Exactly, that’s the missing piece for agents. Congrats on the launch!
AgentKey
@jocky Fair question why it's rare. A single-provider API has nothing to fail over to, so the feature can only exist at the aggregator layer, and most aggregators stop at the billing part. The unglamorous half is aligning providers closely enough that a swap doesn't change your output shape. That part ate way more time than the routing logic itself.
@lxcong Makes sense, the invisible swap is the hard part. Congrats on the launch!
Installing into Claude Code with one command is the right call — most MCP setups still die in config. Does failover switch sources silently, or does the agent get told the data came from a different provider?
AgentKey
@wanarsan_thongklin The agent does get told. Each response includes which provider actually served it, along with the per-call cost, so nothing is hidden from the calling side. The failover decision itself is automatic, but the receipt is right there in the payload.
AgentKey
@wanarsan_thongklin MCPs are incredibly powerful, but we kept seeing people spend more time configuring them than actually using them. We wanted AgentKey to be something you could install and start using with in minutes, not hours :)