OpenTool Docs

You're building an agent. It needs to create GitHub issues, send Slack messages, read Notion pages. So now you're writing OAuth flows, managing token refresh, handling encrypted storage — congratulations, you're no longer building an agent. You're maintaining plumbing.

OpenTool kills that entire layer. One MCP server. Every tool your agent needs. Authenticated, encrypted, audited. You write zero auth code.

If you're writing OAuth code for the third time, something is broken. This fixes it.

This started the way most side projects do — sitting around, looking for something new to build, something worth learning from.

Found Arcade.dev. A tool execution layer for AI agents with managed auth. Dug into it for hours — how it handled OAuth brokering, how tools got registered and discovered, how the execution pipeline worked, how it managed token lifecycle and credential storage. The more I understood it, the more I thought: this is a genuinely good idea, but it's closed-source, hosted, and not something you can own or inspect.

Spent hours in front of Claude going back and forth — breaking the architecture down, figuring out what each layer actually does vs. what's just marketing, designing how an open-source version could work. Then sketched the whole system out:

Then added my own quirks. Encrypted token storage with AES-256-GCM instead of plain-text. A full interactive CLI because I live in the terminal. A dashboard that doesn't suck. Audit logging on every tool execution. Docker Compose so anyone can self-host in 30 seconds.

The core thesis was simple: this should be open-source. Your agent's tool access shouldn't depend on someone else's uptime, someone else's pricing page, someone else's roadmap. If the execution layer is this critical, you should be able to read every line of it.

So that's what this is. Not a startup. Not a pitch deck. Just a tool that exists because someone needed it to exist.

Your tokens should not live in some SaaS dashboard you can't audit. OpenTool runs on your machine. Your tokens stay with you. Everything is inspectable. One command to start.

That spins up four containers. The whole stack:

• → PostgreSQL database
• → Redis for token caching
• → OpenTool server (port 3001)
• → Dashboard (port 3000)

Migrations run on first boot. Schema, seed data, everything. You don't touch SQL. It just works.

One .env file. That's the entire config surface. No YAML nesting hell, no scattered config files across four directories, no "check the wiki for advanced options."

localhost:3000. Four pages. No settings buried in settings. No dashboard that needs a dashboard to manage it.

• Overview — Stats, MCP config snippet, server health. The stuff you actually check.
• Tools — Connect/disconnect providers. One click, OAuth does the rest.
• API Keys — Create, copy, revoke. No key rotation ceremony.
• Settings — Profile. That's it. Not 47 tabs.

Connect a tool from the CLI? Shows up in the dashboard. Connect from the dashboard? Works in the CLI. Same database, same state. Because syncing tools across interfaces shouldn't be a feature — it should be the default.

Not everyone wants to context-switch to a browser to connect a tool. The CLI is a full interactive TUI — login, connect providers, check status, execute tools. All from your terminal. OAuth links are Ctrl+Click-able. You never leave your workflow.

This is the part that actually matters. Most people have 5+ MCP servers in their config — scattered, duplicated, half-broken. OpenTool replaces all of them. One entry. Every tool.

Once configured, your agent sees every connected tool. Connect a new provider in the dashboard or CLI → agent picks it up instantly. No config edit. No restart. No "please reload your MCP servers."

If your MCP setup needs a spreadsheet to track what's connected where, you don't have a system. You have chaos.

120 tools. 24 providers. These aren't wrappers around wrappers — they're direct API calls with proper auth. You can read every line of execution code. Nothing is abstracted away into some plugin system you can't debug.

Most tool frameworks want you to learn their DSL, their config format, their plugin lifecycle. OpenTool doesn't have any of that. A tool is a single TypeScript file. Zod schema in, execute function out. That's the entire API.

Import it in the registry, run the seed script. Your agent can use it immediately. No build step. No plugin manifest. No restart dance.

OAuth provider? Add client ID + secret to the seed script. API key only? Set authType: 'api_key'. Done. If adding a tool takes more than 10 minutes, something is wrong with the framework, not you.

This isn't a corporation asking for free labor. It's a tool that exists because someone got tired of rewriting the same integrations. If you've felt that pain, you already understand the project.

Highest-impact contributions:

• 1. Add a new tool provider — see Adding Tools above. Most providers take under an hour.
• 2. Fix a bug — check open issues. Some are one-liners.
• 3. Improve these docs — you're reading them right now. You know what's confusing.

Half the ecosystem is glue code with branding. If you think a tool should exist, don't file an issue asking for it. Build it. Open a PR. That's how this project grows.