Toolport
# Toolport
[](https://github.com/btsouth/toolport/actions/workflows/ci.yml)
[](https://github.com/btsouth/toolport/releases)
[](LICENSE)
[](https://discord.gg/Xsn27MxdBA)
[](https://glama.ai/mcp/servers/tsouth89/toolport)
**Set up your MCP servers once. Use them in every AI client.**
Toolport is a local gateway for MCP, the protocol that gives AI apps access to
tools like GitHub, Slack, and databases. Connect your servers once, then share
them across Claude, Cursor, Codex, VS Code, and other clients.
[Download](https://toolport.app/download) · [Website & demo](https://toolport.app) · [Discord](https://discord.gg/Xsn27MxdBA)

## Why Toolport?
- **Less context overhead.** Agents search for tools when they need them instead
of loading every tool definition up front. This helps clients that send every
definition on each request, past roughly 10 to 25 tools. Clients with their own
tool search, such as Claude Code, Codex and Cursor, already defer definitions.
See the [benchmarks](BENCHMARK.md).
- **One setup for every client.** Add and authenticate each server once. Use
access sets to choose which servers each client can reach.
- **Keys stay local.** Credentials live in your OS keychain, outside client configs.
- **Control over tool calls.** Disable tools, require approval for destructive
calls, and review activity in one place.
## Get started
1. [Download Toolport](https://toolport.app/download) for Windows, macOS, or Linux.
2. Add a server from the catalog, import an existing setup, or paste a server config.
Curated servers that need launch arguments show a Launch setup section in the app.
3. Authenticate the server, then open **Clients** and connect your AI apps.
Restart or reload the client once so it picks up Toolport.
Installers and release notes are also on
[GitHub Releases](https://github.com/btsouth/toolport/releases).
On Arch and Omarchy, the [pacman repository](docs/arch-pacman-repo.md) keeps
Toolport on your normal update path. It stays on 1.24.2 until the staged 2.x
rollout finishes; use the AppImage for 2.x until then.
Working with a team? [Toolport Teams](https://toolport.app/teams) shares server
configuration and policies while each member keeps their own credentials.
## Documentation
- [Upgrade from 1.24.x to 2.0](docs/migration.md)
- [Supported clients and setup](docs/clients.md)
- [Skills and rules each agent loads](docs/skills-and-rules.md)
- [Access sets, environment variables, and configuration](docs/configuration.md)
- [Headless gateway and Docker](docs/headless.md)
- [Arch and Omarchy install (pacman repository)](docs/arch-pacman-repo.md)
- [Open WebUI](docs/openwebui.md) and [agent plugin](packaging/agent-plugin/toolport/README.md)
- [Security](SECURITY.md) and [troubleshooting](docs/troubleshooting.md)
- [Uninstall](docs/uninstall.md)
- [Changelog](CHANGELOG.md)
## Development
Requires Node.js and stable Rust, plus the platform dependencies described in
[Contributing](CONTRIBUTING.md).
```sh
npm ci
npm run build:gateway
npm run tauri dev
```
See [Contributing](CONTRIBUTING.md) for testing and build instructions.
## Toolport Teams
Share server configuration and policies across a team while each member keeps
their own credentials. [Hosted and self-hosted options](https://toolport.app/teams).
## License
The desktop app and gateway are [MIT licensed](LICENSE).
TDQS
Scored across 4 tools
Each tool has a clearly distinct role: status reports server state, search_tools discovers tools, call_tool invokes them, and fetch_result pages through truncated results. There is no meaningful overlap between any two tools.
All tools share the consistent toolport_ prefix and most follow a verb_noun pattern (search_tools, call_tool, fetch_result). toolport_status is slightly less consistent because it uses a noun without an explicit action verb, but the pattern remains predictable.
Four tools is a well-scoped size for a gateway/meta-server: discovery, invocation, result pagination, and status reporting each earn their place. The set is neither bloated nor thin for its purpose.
The tool set covers the full lifecycle of using a unified MCP gateway: finding tools, invoking them, retrieving large results, and checking server status. There are no obvious dead ends or missing operations for the stated purpose.