Model or dataset
chainbase-labs/Agentkey avatar
chainbase-labs/Agentkey

AgentKey: One Installer That Wires External Data Into 40+ Coding Agents

Connect your AI agent to the world — Web search, Social media, Crypto & On-chain data. One plugin, zero extra config.

648 stars66 forksShellApache-2.0

At a glance

What is it?
AgentKey is a Shell installer and CLI that registers a shared skill and an MCP client entry so agents such as Claude Code, Codex, Gemini CLI and Cursor CLI can reach social, web and on-chain data through one subscription. The interesting part is the DSH integration path, and the part worth checking before you adopt it is what happens when the installer finds a patch it does not recognise.
Who is it for?
Adopt AgentKey if you already run several agents on one machine and want a single credential and a single bill instead of per-provider keys, and if you are willing to depend on the hosted agentkey.app service for the data itself. Do not adopt it if you need a self-contained, offline-capable tool, or if your DSH patches were hand-edited, because the CLI stops rather than guess when it sees an unmarked AgentKey Loader row.
Can I use it commercially?
Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 22 days ago.
What is it written in?
Mainly Shell, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The credential sprawl problem AgentKey is aimed at

The README frames the problem as arithmetic: ten tasks, ten API keys, ten separate bills. An agent asked to summarise recent tweets, read a LinkedIn page, pull a YouTube transcript and check a wallet's recent transactions would otherwise need a credential and a client for each source, and several of those sources return 403 or a login wall to a plain HTTP fetch. AgentKey's answer is to move all of that behind one subscription and one installer, so the agent calls a single capability surface instead of four vendors.

The intended user is someone running an agent that is otherwise capable but blind to live data. The README lists Claude Code, Codex, Gemini CLI and Cursor CLI as common examples and points at a separate skills repository for the full set of 40+ supported agents. It is not aimed at teams building a data pipeline; it is aimed at people who want their existing agent to stop asking a human to paste in a URL's contents.

What the installer actually writes to disk

The install is a piped shell script on macOS and Linux (curl -fsSL https://agentkey.app/install.sh | bash) and a PowerShell equivalent on Windows (irm https://agentkey.app/install.ps1 | iex). According to the README, the installer auto-detects every agent on the machine and configures each one, then opens a browser tab for login. There is no API key to copy and no JSON to edit by hand in the default path.

The DeepSeek Harness section is the one place the README describes the mechanism in detail, and it is worth reading closely because it contradicts the "zero config" impression. The installer looks for ${DSH_HOME:-~/.dsh} or a dsh command. It then installs the AgentKey skill globally at ~/.agents/skills/agentkey, authenticates, and adds a single managed Loader block to the home-level patch at ${DSH_HOME:-~/.dsh}/cordis.patch.yml. That block uses Loader id agentkey, module @deepseek-ai/dsh-mcp-client and MCP serverName agentkey. The README is explicit that this is a CLI-managed DSH MCP integration and not a native installable DSH plugin, and that the home layer is composed over current and future profiles. Tool allow and deny policy still decides whether a given preset, session or subagent can see the tools.

Why DSH needs a device-code login instead of OAuth

This is the most specific technical claim in the material and the one that explains the two-step manual path. DSH 0.1.0-rc.7 does not hand an OAuth authProvider to its MCP SDK client. A header-free server entry therefore cannot complete 401 or RFC 9728 discovery, and it cannot open a browser on its own. The workaround is to let the CLI perform a device-code flow so that a local Bearer key gets written instead.

For a DSH-only manual install the README gives exactly two commands: npx -y skills add chainbase-labs/agentkey -g -a universal -s agentkey -y, followed by npx -y @agentkey/cli --auth-login --only dsh. The CLI stores the real API key only in the single local home patch. Re-running that command rotates the key and replaces the managed block, which is a clean upgrade story as long as nothing else has edited the same region. No existing profile is required for the install to succeed.

The migration path stops rather than guess

During migration the CLI removes only top-level, column-1 AgentKey managed blocks from per-profile patches, and it renames a legacy .agent-presets/agentkey directory to a timestamped backup, printing that backup path. Those two behaviours are the ones to watch in a shared or long-lived DSH setup, because they move files rather than merge them.

The harder boundary is structural detection. If the CLI finds an older, unmarked AgentKey Loader row, it stops without changing any patch and asks you to remove that top-level insert child yourself. That is the right call for a tool that edits configuration it did not write, but it means the upgrade is not fully unattended for anyone who installed an early version by hand. The README notes that symlinked profiles are handled, though the supplied text is truncated at that point, so the exact symlink behaviour is not something I can confirm from this material.

The dependency AgentKey does not remove

AgentKey replaces many credentials with one, but that one lives on a hosted service. The install script, the login flow, the console at console.agentkey.app and the data calls all point at agentkey.app, and the README describes a subscription rather than a self-hosted deployment. There is no mention of running the data layer locally or of a bring-your-own-key mode for the underlying providers. If your constraint is that no external service sees your queries, the installer does not address it, and the Apache-2.0 licence on the repository does not change that, because the licence covers the code you can read, not the service you call.

A second limitation is scope by platform. The README's own examples include Instagram, Douyin, Bilibili, LinkedIn and Reddit, several of which are login-walled or regionally restricted. The README asserts that AgentKey scrapes them, but it does not describe the mechanism or the failure rate. Treat the use-case table as a statement of intent, not a guarantee, and test the specific sources you depend on before standardising on it.

How this differs from a plain MCP server or a scraping library

The obvious alternative is to assemble the same reach yourself: a general MCP server for web fetch plus a scraping library such as a headless browser for the login-walled sites, each with its own key and its own rate limits. The difference in approach is where the maintenance sits. With separate tools you own the credential rotation, the per-site breakage when a page layout changes, and the bill. With AgentKey you own one credential and one bill, and the per-site breakage is someone else's problem until it is not.

The trade is control for surface area. A self-assembled stack lets you pin a scraper version, run it in your own network, and read exactly what it sends. AgentKey's installer is convenient precisely because it hides those decisions, and the DSH section shows how much configuration it is willing to touch on your behalf. If you already have a working fetch and scrape setup that meets your needs, the migration is a downgrade in visibility for an upgrade in breadth.

Maintenance, releases and what to verify first

The repository is Shell, Apache-2.0, on the main branch, with v1.14.0 published on 2026-08-22, roughly two weeks after v1.13.1 and v1.13.0 in early August. That cadence suggests active development, and the README's instruction to re-run the CLI to rotate the key and replace the managed block implies upgrades are meant to be re-runs rather than manual edits. The cost of that model is that anything you add inside the managed block can be overwritten; keep your own customisations outside it.

Apache-2.0 permits commercial use and modification and includes a patent grant, but it also means the repository carries no warranty, and the README itself points at a separate skills repository for the agent list, so part of the integration surface is not in this repository at all. I have not installed or run AgentKey, so I cannot report what the installer prints on a clean machine or how it behaves when two agents share a config directory. Verify three things before a wider rollout: the exact contents of the managed block in ${DSH_HOME:-~/.dsh}/cordis.patch.yml after install, the backup path printed for any renamed .agent-presets/agentkey directory, and whether your specific target platforms return usable data through the subscription.

Editorial conclusion

Adopt AgentKey if you already run several agents on one machine and want a single credential and a single bill instead of per-provider keys, and if you are willing to depend on the hosted agentkey.app service for the data itself. Do not adopt it if you need a self-contained, offline-capable tool, or if your DSH patches were hand-edited, because the CLI stops rather than guess when it sees an unmarked AgentKey Loader row. Before rolling it out, run the installer on one machine, read the printed backup path for any renamed .agent-presets/agentkey directory, and diff the managed block in ${DSH_HOME:-~/.dsh}/cordis.patch.yml against what you had.

Official sources

  1. chainbase-labs/Agentkey on GitHub
  2. License: Apache-2.0
  3. Project website
  4. README
  5. Releases
Community notes

Community notes