Launched this week
AgentKey
One-stop live data marketplace for your agent
1.1K followers
One-stop live data marketplace for your agent
1.1K 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.
Browser Notes
Getting this error when tried to register with google
AgentKey
@daxeelsoni Sorry, we're seeing a sudden surge in new registrations and are currently working on a fix.
AgentKey
@daxeelsoni It has been restored. You can try it again now.
AgentKey
Hey PH , I'm Cong, Founding engineer at Chainbase here. I've spent the past few months building AgentKey, a one-stop live data marketplace for your agent, and I want to share the three problems that took us the longest to get right.
1. Tool discovery
We sit on ~1,800 API endpoints. If you dump those into MCP as static tools, the agent burns ~35,000 tokens of context just loading the definitions, and it still picks the wrong tool half the time. So we built our own intent recognition layer: the agent describes what it wants in plain language, like "find trending sunscreen posts on reddit", and a retrieval model we trained on our own catalog maps that straight to the right endpoint. Param schemas only load for the one tool it actually picks. The whole flow runs on about 1,500 tokens, and it stays that cheap no matter how many endpoints we add.
2. Every agent wants to be integrated differently.
Claude Code, Codex, WorkBuddy, Openclaw ... we support 20+ of them and each has its own quirks. Our answer is a split architecture: a lightweight skill on your machine that auto-detects whatever agents you have and keeps itself updated, plus one standardized MCP server in our cloud that's always current. You set it up once and never think about it again. New endpoints, fixes, upgrades all land on the server side, so there's no local upgrade treadmill to babysit.
3. Upstream APIs are flaky.
Providers rate-limit, degrade, and sometimes just die. We do QoS-based traffic shaping and automatic failover between providers, so when one goes down the request quietly reroutes to a healthy one. Your agent gets an answer instead of a 503.
I'm around all day, happy to answer anything about how this works under the hood.
Every cool MCP server I found wanted its own key from a service with its own signup and its own minimum spend. The unbundling was exhausting. Glad someone rebundled it.
AgentKey
@tammytan516 The signups and billing were the easy part to rebundle. The rest is where it gets fun: same-type providers are interchangeable so failover is automatic, the integrations are ours to maintain instead of yours, and an intent layer picks the right tool so your agent isn't guessing across the whole catalog. You see one bill, your agent sees one catalog.
auto failover on live data feeds is the part I'd want to poke at — when a provider drops mid-request does the agent see a clean retry, or can it get a partial/stale response before the switch kicks in?
AgentKey
@sabber_ahamed Clean failure, always. If a provider drops mid request the agent gets an explicit error back, not a half filled payload dressed up as a result. The retry then goes out as a fresh, full request to a same capability provider from the candidate set. So what eventually lands is one provider's complete response, never two sources stitched together and never a partial one promoted to success. The rule we built around is simple: a bad call should look bad, immediately.
@lxcong good, that's the right instinct — fail loud not quiet. does the candidate set get reordered based on recent error rate, or is it static per request so a flaky provider stays first in line until someone notices?
AgentKey
@sabber_ahamed Two sort keys, both doing work. Relevance to the query first, then backend health within the equivalents, so the ranking follows what our stats are seeing rather than a fixed list. A source that goes flaky slides down by itself instead of squatting first in line.
auto failover is the part everyone skips until prod breaks at 2am. is it keyed off per-source rate limits, or purely latency-based, and does it retry the same provider once before switching?
AgentKey
@sabber_ahamed Both, but earlier than you'd think. Instead of letting calls hit a source's rate limit and bounce, the routing layer does QoS traffic shaping to keep load inside each provider's envelope, with latency and error signals feeding the same picture. Hard failures still surface explicitly to the agent, with equivalent candidates for the retry.
Question: When it fails over between providers, how do you handle differences in response shape or data quality so the agent gets a consistent answer?
AgentKey
@thediffidentgarlicbread honest answer is we don't paper over the differences. Every tool keeps its own real schema, and when the agent picks a replacement from the candidate set it pulls that tool's schema before the retry, so it knows exactly what shape is coming back. Pretending provider B's response looks like provider A's is how you get silent field mismatches, and those are worse than a visible shape change. On quality, the candidate ranking is semantic fit first and live health second, so a fallback is the best remaining equivalent rather than whatever was next in a list.
The auto failover detail is what catches my attention most here. keeping agent workflows from silently dying when one provider 403s or rate limits is the part that's actually painful to build yourself.
Nice to see that addressed upfront.
keep going @yanshuo
AgentKey
@mohammed_messeguem The silent death part is what got us too, a 403 at step three of a twelve step workflow is its own special genre of debugging misery. If you want the gory details, someone in this thread grilled us on the exact failover behavior, candidate ranking included. Worth a scroll, it got pleasantly nerdy.
@lxcong will check it out:)