What can you do with this server?

Kitsune MCP is a gateway server that dynamically discovers, mounts, and unmounts any of 10,000+ MCP servers on demand, minimizing token overhead (~1,187 tokens at rest) while providing full access to external tools when needed. * search(query, registry?, compare?) – Search across 7 registries (official, npm, PyPI, GitHub, Glama, MCPRegistry, Smithery) to discover MCP servers; use compare=True for a side-by-side token cost table. * shapeshift(server_id?, tools=[], server_args=[]) – Mount a server's tools at runtime (optionally loading only a subset for lean context), or call with no arguments to unmount and return to the ~965-token baseline. * call(tool_name, arguments?, server_id?) – Invoke any tool on the currently mounted (or a specified) server. * auto(task, server_hint?, arguments?) – One-shot workflow: automatically searches, mounts, and calls the right server/tool for a given task. * auth(server_id_or_var, value?) – Check or set credentials (env vars or OAuth 2.1), save API keys, trigger browser OAuth flows, or revoke tokens. * status() – View runtime state: provider auth, active server, open connections, session stats, and context bloat detection. Key benefits: 70–95% token savings vs. always-on MCP configs, improved tool-selection reliability by keeping visible tool count low, process isolation for local packages (npm, PyPI, Docker), and advanced developer tools (schema inspection, benchmarking, custom tool registration) when KITSUNE_TOOLS=all.

Which integrations are available for this server?

Provides web search capabilities through the Brave Search API, allowing AI agents to perform internet searches and retrieve information from the web. Enables interaction with GitHub repositories and platform features through the GitHub MCP server, allowing AI agents to manage code, repositories, and development workflows. Provides database and backend service integration through Supabase, allowing AI agents to interact with PostgreSQL databases, authentication, and other Supabase features.

de en es ja ko ru zh

kitsune-mcp

by kaiser-data

Overview Schema Related Servers Score Discussions

Python

Hybrid

PyPI npm MCP Registry Python Coverage License: MIT Smithery Glama Discord

Kitsune is a runtime MCP proxy: one always-on gateway your agent uses to reach the rest of the ecosystem. search finds a server across 7 registries. shapeshift(id) mounts its tools in the current turn. shapeshift() drops them. No config edit. No client restart.

search → shapeshift → call → shapeshift()       # reach, use, release
connect → shapeshift → edit → reload → call     # MCP REPL (default install)

Install for reach and live execution — not for token savings. Native Tool Search already defers schemas for servers you've configured. Kitsune covers what Tool Search cannot: servers you've never set up, servers you're writing right now, and community packages you want to try without wiring them into mcp.json forever.

	Loop	Why it wins
MCP REPL	edit → `reload` → `call`	Iterate on your own server without killing the session
Long-tail reach	`search` → `shapeshift` → `call`	One-offs and obscure APIs with no pre-install
Try-before-you-trust	`confirm=True` + Docker cage on by default + TOFU pins	Community catalog without blind always-on installs

Use Kitsune when…	Skip it when…
You're building an MCP and need an edit/reload loop	You only need 1–3 trusted servers (configure them natively)
A task needs a server that isn't in your config	Every turn hits the same server (keep it always-on)
CLI flag-guessing on a long-tail API is too risky	You want cheaper tokens — floor is ~1,774 tokens/turn, additive on modern clients
You want to evaluate community MCP code safely	Unattended prod admin/billing/security keys (Safety)
You're consolidating a crowded MCP config (GATEWAY)	You need sub-second first call (cold mount ~1–15s — `prewarm` or always-on)

Worked high-stakes flows (IAM, IR, audits): examples/scenarios/. CLI vs MCP accuracy argument lives there too — short version: models nail common CLI commands and fail on the long tail; Kitsune mounts schemas only while you need them.

Related MCP server: mcphub

Installation

pip install kitsune-mcp      # recommended
# or
uvx kitsune-mcp              # isolated env via uv, no venv setup
# or
npx kitsune-mcp              # npm (delegates to uvx internally)

Requirements: Python 3.12+ · node/npx for npm-based servers · uvx from uv for PyPI-based servers · Docker optional (sandbox)

Add once to your MCP client config:

{
  "mcpServers": {
    "kitsune": { "command": "kitsune-mcp" }
  }
}

Client	Config file
Claude Desktop (macOS)	`~/Library/Application Support/Claude/claude_desktop_config.json`
Claude Desktop (Windows)	`%APPDATA%\Claude\claude_desktop_config.json`
Claude Code	`~/.claude/mcp.json`
Cursor / Windsurf	`~/.cursor/mcp.json`
Cline / Continue.dev	VS Code settings / `~/.continue/config.json`

Also works with OpenClaw, Zed, and any MCP-compatible client.

Lean profile at rest: 9 tools · ~1,774 tokens/turn (status, search, auth, shapeshift, call, auto, plus the connect / release / reload REPL trio) — measured via python examples/benchmark.py.

Quick start

Borrow a server you never configured:

search("web scraping")
shapeshift("firecrawl", tools=["scrape_url"])   # surgical: one tool, not the whole surface
call("scrape_url", arguments={"url": "https://example.com"})
shapeshift()                                    # drop form — session stays up

Community / long-tail (confirm; caged by default):

search("pdf", registry="glama")
shapeshift("mcp-pdf-tools", confirm=True)  # npm/PyPI caged in Docker by default (when available)
call("extract_text", arguments={"path": "report.pdf"})
shapeshift("mcp-pdf-tools", confirm=True, sandbox=False)  # opt out of the cage
shapeshift()

Hosted (Smithery HTTP — needs a free SMITHERY_API_KEY):

search("exa", registry="smithery")
shapeshift("exa")
call("web_search_exa", arguments={"query": "MCP registry growth 2026"})
shapeshift()

Credentials mid-session:

auth("BRAVE_API_KEY", "sk-...")
shapeshift("brave", tools=["brave_web_search"])
call("brave_web_search", arguments={"query": "MCP protocol 2026"})
shapeshift()

One-shot — pass server_hint when you know the id (auto without it is best-effort and can misfire):

auto("current time in Tokyo", server_hint="mcp-server-time")

Full live walkthrough: docs/demo-realtime.md.

Developing an MCP server live

Building an MCP normally means: edit → restart client → lose session → re-test. Kitsune turns that into an MCP REPL in one session — and connect / release / reload are in the default lean profile, so this works on a plain pip install with no KITSUNE_TOOLS=all.

connect("uvx --from . my-mcp-server", name="dev")       # start child process
shapeshift("dev")                                       # mount tools → client sees them
call("summarize", arguments={"url": "https://example.com"})

# … edit the tool in your editor …

reload("dev")                                           # release → restart fresh code → remount, one call
call("summarize", arguments={"url": "https://example.com"})

reload("dev") folds the whole cycle — kill the stale process, start your edited code, remount so the client sees the new schemas — into a single call. It also removes the classic footgun: calling connect() again after an edit without releasing first hands you back the old process; reload always releases first.

Local connect() targets are untrusted (confirm / KITSUNE_TRUST apply). Process isolation ≠ security sandbox — see Safety model. Companion skill: kitsune-dev.

How it works

shapeshift(server_id) picks a transport (stdio / HTTP+SSE / WebSocket / Docker), connects, fetches tools/list, and registers each tool as a native FastMCP tool with the server's real schema. The client gets notifications/tools/list_changed and sees first-class tools — no wrapper indirection.

shapeshift() with no args deregisters proxies, closes the connection, and returns to the lean baseline.

Mental model — tool-schema RAG: index the ecosystem → search retrieves candidates → shapeshift(..., tools=[…]) injects only what's needed → agent calls natively → shapeshift() evicts.

Source	Transport
npm	`npx <package>` (local; optional Docker sandbox)
PyPI	`uvx <package>` (local; optional Docker sandbox)
GitHub	`npx github:user/repo` or `uvx --from git+…`
Smithery hosted	HTTP + SSE (`SMITHERY_API_KEY`)
WebSocket	`ws://` / `wss://`
Docker image	`docker run …` hardened profile

Tool reference

Lean (default)

Tool	Signature	Role
`status()`	—	Current form, pool, GATEWAY scan, session stats
`search()`	`query, registry?, compare?`	Fan-out across 7 registries
`auth()`	`server_or_var, value?`	Env keys + OAuth 2.1 browser flow / logout
`shapeshift()`	`server_id?, tools=[], …`	Mount / unmount; `tools=[…]` surgical; `confirm=True`; caged by default (`sandbox=False` opts out)
`call()`	`tool_name, arguments`	Invoke; server inferred when mounted
`auto()`	`task, server_hint=, arguments=`	search → mount → call (prefer `server_hint`)

Forge (KITSUNE_TOOLS=all or kitsune-forge): connect, release, prewarm, inspect, test, bench, compare, craft, run, fetch, setup, skill, shiftback, … — see For MCP developers.

Server sources

Registry	Auth	`registry=`
modelcontextprotocol/servers	—	`official`
registry.modelcontextprotocol.io	—	`mcpregistry`
Glama	—	`glama`
npm	—	`npm`
PyPI	—	`pypi`
GitHub	—	`github:owner/repo`
Smithery	Free API key	`smithery`

search() fans out across no-auth registries by default. Add SMITHERY_API_KEY for hosted HTTP servers (no local install).

Safety model

Reach into 130k community servers only works if unknown code can be contained. Consent, sandbox, and pins are product features — not footnotes.

Headline controls

confirm=True (or KITSUNE_TRUST) before community / local mounts
Community npm/PyPI mounts cage in hardened Docker by default (when Docker is present); sandbox=False or KITSUNE_SANDBOX=off opts out, sandbox=True forces it, KITSUNE_SANDBOX=all cages every local mount
TOFU pins in ~/.kitsune/pins.json — later malicious publishes don't silently replace what you already ran

What it protects against

1. Unverified code without consent

Tier	Sources	On mount
High	`official`	runs directly
Medium	`mcpregistry`, `glama`, `smithery`	runs directly
Community	`npm`, `pypi`, `github`, local `connect()`	requires `confirm=True`

KITSUNE_TRUST=community waives the gate; status() warns when that override is active.

confirm=True is not a human-approval boundary. The model can set it. Real approval belongs in your client's tool-approval UI.

2. Shell injection at spawn. Install commands are validated (no & ; | $ \ \n / ../) and launched with create_subprocess_exec — no shell. Vets the launch line, not what the package does once running.

3. SSRF. fetch() and registry HTTP are HTTPS-only; private/loopback/non-global hosts blocked; every redirect hop re-validated (KITSUNE_ALLOW_LOCAL_FETCH=1 to opt out).

4. Credential exposure. ~/.kitsune/.env and oauth/ at mode 0600; OAuth 2.1 + PKCE S256 + DCR (RFC 7591); missing-cred warnings before calls; auth(id, "logout") clears tokens (RFC 7009 where available).

5. Docker sandbox for untrusted local servers — on by default. Community npm/pypi/github mounts (and the auto()/call()/run() exec paths) cage automatically when Docker is on PATH; no host FS, --cap-drop ALL, read-only rootfs, RAM/PID caps. Cred env vars forwarded by name only (docker -e KEY) — never in argv, ps, or the pool key. First sandboxed mount pulls node:22-slim / uv:python3.13-bookworm-slim. Best-effort: no Docker → runs uncaged with a nudge (an explicit sandbox=True hard-fails instead). Opt out per-call with sandbox=False or session-wide with KITSUNE_SANDBOX=off. Filesystem-style servers need host paths and don't fit the sandbox.

What it does NOT do

Cage needs Docker + opt-in-trusted sources. Community mounts cage by default only when Docker is present; without it (or with sandbox=False/KITSUNE_SANDBOX=off, or for medium/high-trust sources) local stdio runs as your user — full FS, network, inherited env. Process isolation ≠ a security boundary.
Docker ≠ kernel boundary. Hardened flags blunt escalation / fork bombs / FS tampering; not a guarantee against container escape. No default non-root / --network none (most servers need egress).
TOFU ≠ digest pin. Pins a version, not a content hash. github: / git+ / hand-written connect() commands aren't pinned. High assurance: pin by digest or vendor.
Tools first. Resource/prompt proxying is narrower (URI templates skipped; HTTP path differs). "Any server" means tool execution.

Bottom line: strong for supervised developer and personal use. Do not run unattended with production admin, billing, or security credentials in default local mode. Keep Docker installed so the default cage engages, and prefer client approval for untrusted packages.

See guards live: docs/demo-realtime.md.

GATEWAY: consolidate always-on servers

Optional. Keep daily drivers (GitHub, filesystem, …) native if you prefer. When a config is crowded, status() flags other always-on servers so you can collapse to one Kitsune entry and reach them via shapeshift:

GATEWAY
  ⚠  1 other server(s) active in claude-desktop (~8 extra tools in context)
     Run setup() to harvest their credentials and reduce bloat

setup()                    # preview
setup(action="harvest")    # keys → ~/.kitsune/.env (non-destructive)
setup(action="absorb")     # register for shapeshift()
setup(project=True)        # project mcp.json with only Kitsune

Never modifies existing configs without explicit confirmation. (setup is forge-profile.)

Performance

Connection latency (what you feel)

Warm pool re-attach within a session: 0 ms.

Transport	Cold start	Warm
HTTP / Smithery	0–1.4 s	0.0 s
Local `npx`	1.7–6.3 s	0.0 s
Local `uvx`	1.0–5.2 s	0.0 s

Use prewarm (forge) when you know you'll need a server soon.

Token overhead (secondary)

Real vs fully-mounted always-on or clients without Tool Search. On Claude Code 2.1.7+ with native deferral, this is mostly not a Kitsune-specific win. Product pitch is reach + REPL above — not this table.

Every Kitsune figure includes the ~1,774 floor. Reproduce: python examples/benchmark.py. Methodology: docs/benchmarks.md.

Server	Always-on	Surgical + floor	vs always-on
`mcp-server-time`	261	~2,035	always-on cheaper ¹
`mcp-server-git`	1,242	~2,084	always-on cheaper ¹
`server-memory`	2,615	~2,354	10%
`server-filesystem`	3,207	~2,464	23%
`brave`	3,612	~2,224	38%
`server-github`	4,229	~2,074	51%
`notion-hosted`	13,707	~3,724	73%

¹ Break-even: Kitsune pays off past one medium server, or two-plus small ones sharing the single floor. Multi-server stack (GitHub+fs+git → Notion suite): ~72–85% vs fully-mounted always-on — same caveat as above.

Fewer visible tools also helps selection reliability (Gorilla / ToolBench); on modern clients Tool Search delivers much of that focus for configured servers. Kitsune-specific accuracy bench: not yet — contributions welcome.

Configuration

Env and `.env`

Re-read on every shapeshift / call — add keys mid-session, no restart.

Search order: CWD/.env → ~/.env → ~/.kitsune/.env (last wins).

auth("BRAVE_API_KEY", "sk-...")    # → ~/.kitsune/.env

Tool surface

{ "env": { "KITSUNE_TOOLS": "shapeshift,call,auth" } }   # subset
{ "env": { "KITSUNE_TOOLS": "all" } }                    # forge

State directory

Default ~/.kitsune/ (credentials, pins, OAuth, session). Relocate with KITSUNE_HOME=/tmp/kitsune-iso.

Sandbox / trust policy

KITSUNE_SANDBOX=community   # Docker-cage community npm/PyPI mounts
KITSUNE_SANDBOX=all         # cage every local mount
KITSUNE_TRUST=community     # waive confirm gate (status warns)
KITSUNE_REPIN=1             # adopt newer pinned version

Smithery

{ "env": { "SMITHERY_API_KEY": "your-key" } }

Free key: smithery.ai/account/api-keys. Without it, npm / PyPI / official / GitHub still work.

Mount patterns

Switch forms mid-session — take only the slice you need:

# Research
shapeshift("brave", tools=["brave_web_search"])
shapeshift("mcp-server-fetch")
shapeshift("@modelcontextprotocol/server-memory", tools=["read_graph", "search_nodes"])

# Code
shapeshift("@modelcontextprotocol/server-filesystem",
           tools=["read_file", "write_file", "edit_file"],
           server_args=["/path/to/project"])
shapeshift("mcp-server-git", tools=["git_status", "git_diff", "git_log"])

# Notes
shapeshift("notion-hosted", tools=["notion-search", "notion-append-block-children"])
shapeshift("@modelcontextprotocol/server-memory", tools=["add_memory", "search_nodes"])

shapeshift()   # always drop when the task is done

For MCP developers

{ "command": "kitsune-mcp", "env": { "KITSUNE_TOOLS": "all" } }

Tool	Role
`connect` / `release` / `prewarm`	MCP REPL + warm pool
`inspect(server_id)`	Schemas, live cred check, measured cost
`test(server_id)`	Quality score 0–100
`bench(server_id, tool, args)`	Latency p50 / p95 / min / max
`compare(query)`	Side-by-side cost, tools, trust, creds
`craft(name, description, params, url)`	Register a live HTTP-backed tool

Test inside real Claude / Cursor sessions — not only an inspector UI. Companion skills: kitsune-dev, kitsune-improve.

Why Kitsune?

In Japanese folklore the Kitsune (狐) is known for what it can become: borrow a form, use that power, cast it off, return to itself.

That is the product loop — reach, use, release; or edit, reload, re-test. One config entry. Long tail one call away. Session intact.

shapeshift() is a literal mid-session mount, not a metaphor. Durable advantages: reach, live development, contained try-before-trust — not a smaller token bill on clients that already defer schemas.

I am not Japanese, and I use this name with the highest respect for the mythology and culture it comes from. The parallel felt too precise to ignore.

Contributing

make dev     # install with dev dependencies
make test    # pytest
make lint    # ruff

Issues and PRs: github.com/kaiser-data/kitsune-mcp · CHANGELOG.md

MIT License · Python 3.12+ · Built on FastMCP

Available Tools

8 tools

authA

Check or set credentials. ALL_CAPS = env var; server-id = creds check or OAuth.

auth('GITHUB_TOKEN', 'ghp_...') # save env var auth('GITHUB_TOKEN') # check if set auth('server-id') # show creds needed / run OAuth auth('server-id', 'logout') # revoke OAuth tokens

ParametersJSON Schema

Name	Required	Description	Default
`value`	No
`server_id_or_var`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavior fully. It covers multiple modes (set, check, OAuth, logout) but does not detail side effects such as persistent storage or network calls. The examples are helpful but the description could be more explicit about underlying actions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, using code examples to convey behavior efficiently. Every line adds value, and the structure is front-loaded with the overall purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description covers key usage scenarios adequately. It could mention error handling or synchronization behavior, but for a credential management tool it's sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, yet the description adds rich meaning to both parameters via examples. It clarifies that server_id_or_var can be an env var name or server ID, and value can be a token or 'logout', which is far beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the tool's purpose: checking or setting credentials. Examples differentiate between env var and OAuth operations, and sibling tools (auto, call, etc.) are unrelated, so it stands out.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage patterns via examples (e.g., auth('GITHUB_TOKEN', 'ghp_...') for saving, auth('server-id') for OAuth). It implies when to use, but lacks explicit alternatives or when-not-to-use guidance, which is acceptable for a dedicated auth tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

autoB

search → pick server → infer args → call. Use when you don't know which server to use.

auto('what time in Tokyo') auto('list issues on acme/api', server_hint='github')

ParametersJSON Schema

Name	Required	Description	Default
`keys`	No
`task`	Yes
`arguments`	No
`tool_name`	No
`server_hint`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It describes the workflow (search, pick server, infer args, call) but does not mention potential side effects, error behavior, or whether calls are read-only or destructive. The agent is left guessing about safety and outcomes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences plus two examples. Every word adds value, no fluff. The examples are well-chosen and demonstrate usage patterns effectively.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (automatic server selection, argument inference, calling other tools), the description is too sparse. It lacks details on return values (though an output schema exists), error handling, and the inference mechanism. Sibling tools like 'search' and 'call' are not explained in context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema_description_coverage, the description should clarify parameter meanings. It only hints at 'task' and 'server_hint' via examples but does not explain 'tool_name', 'arguments', or 'keys'. The schema lists these but provides no descriptions, leaving the agent underinformed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: an auto-routing orchestrator that searches for a server, picks it, infers arguments, and calls. Examples clarify usage with natural language tasks. It distinguishes from sibling tools like 'search' and 'call' by automating server selection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use: 'Use when you don't know which server to use.' It also provides illustrative examples. However, it does not specify when not to use or mention alternative tools like 'call' for direct invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

callA

Invoke a tool on an MCP server. Returns the tool's response as text.

Routes through the warm pooled transport when a server is shapeshifted; otherwise spins up a transient transport for the given server_id. Records the call in session stats. Long responses (HTML, large outputs) are truncated with a continuation note.

Use when: the tool name and target server are known. Avoid when: discovery is needed — auto() does search → pick → call in one step.

call('get_current_time', arguments={'timezone': 'UTC'}) # after shapeshift call('list_directory', '@mcp/server-fs', {'path': '/tmp'}) # ad-hoc one-shot

ParametersJSON Schema

Name	Required	Description
`config`	No
`arguments`	No	Tool arguments matching its inputSchema (default {})
`server_id`	No	Defaults to the currently shapeshifted form when omitted
`tool_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description fully discloses routing behavior (warm pooled vs transient transport), session stats recording, and truncation of long responses with continuation note. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise at 5 sentences, front-loaded with core purpose and behavior, includes clear usage examples with no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers key behaviors: invocation, routing, stats, truncation. Lacks error handling description, but given output schema exists and tool is straightforward, it is nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%; description provides usage examples that illustrate tool_name, arguments, and server_id usage but does not explain config parameter. Examples add value but not full semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Invoke a tool on an MCP server' with specific verb and resource. Provides examples and distinguishes from sibling 'auto' which does search->pick->call in one step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use when: the tool name and target server are known. Avoid when: discovery is needed — auto() does search → pick → call in one step.' Names alternative tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

connectC

Start a persistent server. command: server_id or shell cmd (e.g. 'uvx voice-mode'). name: alias for release().

ParametersJSON Schema

Name	Required	Description	Default
`name`	No
`command`	Yes
`timeout`	No
`inherit_stderr`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose all behavioral traits. It mentions 'persistent server' but omits details on side effects, required permissions, or lifecycle, leaving significant gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences, but the second sentence is terse and slightly confusing ('alias for release()'). It is efficient but could be clearer.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters, no annotations, and an output schema that is not described, the description lacks completeness. Key behavioral aspects (e.g., return values, error handling) are omitted.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains 'command' and 'name' but does not address 'timeout' or 'inherit_stderr', offering only partial help.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool starts a persistent server, which is a specific verb+resource. However, it does not effectively distinguish this tool from siblings like 'reload' or 'auto', leaving some ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives is provided. The description implies a range of commands but does not specify prerequisites or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

reloadA

Reload a persistent connection after editing its code — the MCP REPL in one call.

reload('dev') # release the stale process, start fresh code, remount live

Replaces the manual release() + connect() + shapeshift() cycle and removes the "connect() handed back the old process" footgun (it always releases first). name is the alias you gave connect().

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description fully discloses the internal steps: release stale process, start fresh code, remount live, and always releases first. No annotations exist, so the description carries the full burden. It could add more on error handling or prerequisites.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences plus a concise example; every sentence adds value. The description is front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, behavior, parameter meaning, and usage context. With an output schema present, return values are not needed. It could mention prerequisites like having an active connection, but overall it is near complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates by explaining that 'name' is the alias from connect(). This adds clear meaning, though it could include format or validation constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reloads a persistent connection after editing its code, and distinguishes it from siblings by explaining it replaces the manual release+connect+shapeshift cycle, making the purpose and differentiation explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to use after editing code and replaces the manual cycle, providing clear context. However, it does not explicitly state when not to use it versus other single tools like connect.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

searchA

Discover MCP servers across registries — the entry point to mounting.

Returns a ranked list of server_ids with name, description, source, and credential-readiness status. Records discovered servers in session so status() can summarize them. Reports per-registry failures inline rather than failing the whole call.

Use when: you need to find a server matching a capability before mounting. Avoid when: the server_id is already known — go straight to shapeshift() or inspect().

search('web search') # find candidates search('postgres', compare=True) # side-by-side token-cost table search('vector db', registry='smithery')

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes	Keywords, capability description, or natural-language phrase
`compare`	No	Return a side-by-side token-cost comparison table
`registry`	No		all

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses that the tool returns a ranked list of server_ids with specific fields, records discovered servers in session for status(), and reports per-registry failures inline. This is thorough but could mention pagination or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with short paragraphs, bulleted examples, and clear sections. Every sentence is informative without superfluous words. The use of code blocks for examples aids readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given complexity (multiple registries, comparison feature, session recording), the description covers purpose, usage, parameters, and behavioral details. Output schema exists, so return values are unnecessary. Slight gap: no mention of error handling beyond inline failures.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50% (query and compare have descriptions; registry and limit only have titles). The description adds value by listing possible registry values ('all|official|...') and explaining the compare parameter with an example. Limit is not elaborated but has a default, so overall good compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool discovers MCP servers across registries and is the entry point to mounting. It explicitly uses the verb 'discover' and distinguishes itself from siblings like shapeshift() and inspect() by noting when to avoid it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit 'Use when' and 'Avoid when' guidance, including example invocations with different parameters and a note on the 'compare' option. Clearly differentiates from alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

shapeshiftA

Mount an MCP server's tools at runtime. Empty server_id unmounts.

shapeshift('mcp-server-time') # mount (community sources cage by default) shapeshift('id', tools=['only_this']) # lean — mount only listed tools shapeshift('id', sandbox=False) # opt out of the default Docker cage shapeshift('id', sandbox=True) # force the cage (hard-fail if no Docker) shapeshift() # unmount + kill process

sandbox: None (default) cages low-trust npm/PyPI/github sources in Docker when it's available (best-effort — runs uncaged with a nudge if not); True forces the cage; False opts out. source: auto|local|smithery|official. confirm=True for community sources.

ParametersJSON Schema

Name	Required	Default
`keep`	No
`tools`	No
`source`	No	auto
`confirm`	No
`sandbox`	No
`server_id`	No
`server_args`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It explains sandbox behavior in detail (best-effort, force, opt-out), the confirm parameter for community sources, and the unmounting process. It does not elaborate on potential side effects like process termination beyond unmounting, but coverage is solid.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with code-like examples and clear sections. It is somewhat lengthy but each line adds value. Could be slightly more concise without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (7 parameters, no required, 0% schema coverage), the description is highly complete. It covers main functionality, parameter behaviors, and example usages. An output schema exists, so return values are not required in the description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description adds substantial meaning beyond the schema. It explains the key parameters: server_id (empty unmounts), sandbox (None default, True forces, False opts out), source (auto|local|smithery|official), confirm (for community sources), and tools (via examples). This is comprehensive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Mount an MCP server's tools at runtime.' It provides specific verb+resource actions, including mounting, unmounting, and various configurations. The examples distinguish it from sibling tools like reload, search, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit examples of when to use different options (e.g., mounting with specific tools, sandbox modes, unmounting). It does not explicitly state when not to use the tool, but the context is clear enough to infer appropriate use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

statusA

Show Kitsune runtime state: providers, current form, connections, token stats.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description indicates a read-only operation ('show') but with no annotations, it does not explicitly disclose behavioral traits like side effects, auth requirements, or rate limits. Adequate but lacks detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that is informative and front-loaded with the purpose. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Low complexity with no parameters and existing output schema. The description covers the key details of what state is shown, making it complete for its purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters and 100% schema coverage, the description does not need to add parameter info. The baseline for 0 parameters is 4, and the description is sufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool shows Kitsune runtime state, listing specific aspects: providers, current form, connections, token stats. This is a specific verb+resource and distinguishes from siblings like auth or call.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for checking runtime state but does not explicitly state when to use versus alternatives or provide exclusion criteria. No guidance on prerequisites or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv0.21.0Jul 24, 2026

Addedconnect
Addedreload

Changedshapeshift1 field changed

addedInput schema / properties / sandbox

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Sandbox"
+}

2 tool updatesv0.20.5May 16, 2026
- Changedcall2 fields changed
  - addedInput schema / properties / arguments / description
```
Added value: +"Tool arguments matching its inputSchema (default {})"
```
  - addedInput schema / properties / server_id / description
```
Added value: +"Defaults to the currently shapeshifted form when omitted"
```
- Changedsearch2 fields changed
  - addedInput schema / properties / compare / description
```
Added value: +"Return a side-by-side token-cost comparison table"
```
  - addedInput schema / properties / query / description
```
Added value: +"Keywords, capability description, or natural-language phrase"
```

5 tool updatesv0.20.3May 16, 2026

Changedauth2 fields changed

removedInput schema / properties / server_id_or_var / description

Removed value: -"Either an environment-variable name (ALL_CAPS, e.g. 'GITHUB_TOKEN') or a server identifier (e.g. 'mcp-server-time', '@octocat/repo-server'). The shape of this argument selects the operation."

removedInput schema / properties / value / description

Removed value: -"Credential value to store (when first arg is an env var name), or the literal 'logout' to revoke OAuth tokens (when first arg is an OAuth server id). Leave empty to query state."

Changedauto5 fields changed

removedInput schema / properties / arguments / description

Removed value: -"Optional arguments object. If omitted, auto() infers arguments from the task using category-specific adapters (timezone, owner/repo, search query, etc.)."

removedInput schema / properties / keys / description

Removed value: -"Inline credentials to persist before calling — e.g. {'GITHUB_TOKEN': 'ghp_...'}. Stored to ~/.kitsune/.env (mode 0600)."

removedInput schema / properties / server_hint / description

Removed value: -"Pin the server instead of searching. Accepts a server_id or package name. Use when you already know which provider to use."

removedInput schema / properties / task / description

Removed value: -"Natural-language description of what you want done — e.g. 'what time is it in Tokyo', 'search the web for X', 'list issues on owner/repo'. Used to pick a server and infer args."

removedInput schema / properties / tool_name / description

Removed value: -"Optional specific tool name to invoke. If omitted, auto() picks the best-matching tool from the chosen server's schema."

Changedcall4 fields changed

removedInput schema / properties / arguments / description

Removed value: -"Arguments object for the tool, matching its inputSchema. Example: {'path': '/tmp'} for filesystem.list_directory. Defaults to an empty object."

removedInput schema / properties / config / description

Removed value: -"Per-call credential overrides for servers that need them (rarely needed — prefer auth() to persist credentials to ~/.kitsune/.env). Keys are credential names declared by the server."

removedInput schema / properties / server_id / description

Removed value: -"Target server identifier. Optional when a server is currently shapeshifted — defaults to the active form. Accepts package names, registry slugs, or full HTTP(S) URLs for ad-hoc servers."

removedInput schema / properties / tool_name / description

Removed value: -"Name of the tool to invoke on the target server. Use the bare tool name (e.g. 'get_current_time') — Kitsune routes it to the currently shapeshifted server, or to server_id if provided."

Changedsearch7 fields changed

removedInput schema / properties / compare / description

Removed value: -"If True, return a side-by-side token-cost comparison table instead of the default list — useful before committing to a shapeshift() target."

removedInput schema / properties / limit / description

Removed value: -"Maximum number of results to return (typical range 1-20)."

removedInput schema / properties / limit / maximum
```
Removed value: -50
```
removedInput schema / properties / limit / minimum
```
Removed value: -1
```

removedInput schema / properties / query / description

Removed value: -"Search phrase — keywords, capability description, or natural language. Examples: 'web search', 'github issues', 'postgres', 'fetch and summarize web pages'."

removedInput schema / properties / registry / description

Removed value: -"Which registry/registries to search. 'all' (default) fans out across every configured source; pass a specific one to scope."

removedInput schema / properties / registry / examples

Removed value: -[
-  "all",
-  "official",
-  "mcpregistry",
-  "glama",
-  "npm",
-  "smithery",
-  "pypi"
-]

Changedshapeshift7 fields changed

removedInput schema / properties / confirm / description

Removed value: -"Bypass the community-trust gate after reviewing the server. Required for npm/github/glama-via-github sources unless KITSUNE_TRUST=community is set in the environment."

removedInput schema / properties / keep / description

Removed value: -"On unmount (empty server_id), keep the subprocess in the pool for fast re-attach. Default False — fully cleans up on unmount."

removedInput schema / properties / server_args / description

Removed value: -"Extra CLI arguments appended to the server's install command — e.g. ['/private/tmp'] to scope the filesystem server to a directory."

removedInput schema / properties / server_id / description

Removed value: -"Server identifier to mount — npm package, PyPI package, registry slug, or full HTTP(S) URL. Leave empty to unmount the current form. Examples: 'mcp-server-time', '@modelcontextprotocol/server-filesystem', 'https://api.example.com/mcp'."

removedInput schema / properties / source / description

Removed value: -"Registry/install source preference. 'auto' picks the best available; 'local' forces npx/uvx install (downloads + runs locally); 'smithery' requires SMITHERY_API_KEY; 'official' restricts to the verified MCP registry."

removedInput schema / properties / source / examples

Removed value: -[
-  "auto",
-  "local",
-  "smithery",
-  "official"
-]

removedInput schema / properties / tools / description

Removed value: -"Optional allowlist of tool names to mount — load only these instead of the full toolset. Use to keep context lean when a server exposes many tools you don't need."

5 tool updatesv0.20.2May 16, 2026

Changedauth2 fields changed

addedInput schema / properties / server_id_or_var / description

Added value: +"Either an environment-variable name (ALL_CAPS, e.g. 'GITHUB_TOKEN') or a server identifier (e.g. 'mcp-server-time', '@octocat/repo-server'). The shape of this argument selects the operation."

addedInput schema / properties / value / description

Added value: +"Credential value to store (when first arg is an env var name), or the literal 'logout' to revoke OAuth tokens (when first arg is an OAuth server id). Leave empty to query state."

Changedauto5 fields changed

addedInput schema / properties / arguments / description

Added value: +"Optional arguments object. If omitted, auto() infers arguments from the task using category-specific adapters (timezone, owner/repo, search query, etc.)."

addedInput schema / properties / keys / description

Added value: +"Inline credentials to persist before calling — e.g. {'GITHUB_TOKEN': 'ghp_...'}. Stored to ~/.kitsune/.env (mode 0600)."

addedInput schema / properties / server_hint / description

Added value: +"Pin the server instead of searching. Accepts a server_id or package name. Use when you already know which provider to use."

addedInput schema / properties / task / description

Added value: +"Natural-language description of what you want done — e.g. 'what time is it in Tokyo', 'search the web for X', 'list issues on owner/repo'. Used to pick a server and infer args."

addedInput schema / properties / tool_name / description

Added value: +"Optional specific tool name to invoke. If omitted, auto() picks the best-matching tool from the chosen server's schema."

Changedcall4 fields changed

addedInput schema / properties / arguments / description

Added value: +"Arguments object for the tool, matching its inputSchema. Example: {'path': '/tmp'} for filesystem.list_directory. Defaults to an empty object."

addedInput schema / properties / config / description

Added value: +"Per-call credential overrides for servers that need them (rarely needed — prefer auth() to persist credentials to ~/.kitsune/.env). Keys are credential names declared by the server."

addedInput schema / properties / server_id / description

Added value: +"Target server identifier. Optional when a server is currently shapeshifted — defaults to the active form. Accepts package names, registry slugs, or full HTTP(S) URLs for ad-hoc servers."

addedInput schema / properties / tool_name / description

Added value: +"Name of the tool to invoke on the target server. Use the bare tool name (e.g. 'get_current_time') — Kitsune routes it to the currently shapeshifted server, or to server_id if provided."

Changedsearch7 fields changed

addedInput schema / properties / compare / description

Added value: +"If True, return a side-by-side token-cost comparison table instead of the default list — useful before committing to a shapeshift() target."

addedInput schema / properties / limit / description

Added value: +"Maximum number of results to return (typical range 1-20)."

addedInput schema / properties / limit / maximum
```
Added value: +50
```
addedInput schema / properties / limit / minimum
```
Added value: +1
```

addedInput schema / properties / query / description

Added value: +"Search phrase — keywords, capability description, or natural language. Examples: 'web search', 'github issues', 'postgres', 'fetch and summarize web pages'."

addedInput schema / properties / registry / description

Added value: +"Which registry/registries to search. 'all' (default) fans out across every configured source; pass a specific one to scope."

addedInput schema / properties / registry / examples

Added value: +[
+  "all",
+  "official",
+  "mcpregistry",
+  "glama",
+  "npm",
+  "smithery",
+  "pypi"
+]

Changedshapeshift7 fields changed

addedInput schema / properties / confirm / description

Added value: +"Bypass the community-trust gate after reviewing the server. Required for npm/github/glama-via-github sources unless KITSUNE_TRUST=community is set in the environment."

addedInput schema / properties / keep / description

Added value: +"On unmount (empty server_id), keep the subprocess in the pool for fast re-attach. Default False — fully cleans up on unmount."

addedInput schema / properties / server_args / description

Added value: +"Extra CLI arguments appended to the server's install command — e.g. ['/private/tmp'] to scope the filesystem server to a directory."

addedInput schema / properties / server_id / description

Added value: +"Server identifier to mount — npm package, PyPI package, registry slug, or full HTTP(S) URL. Leave empty to unmount the current form. Examples: 'mcp-server-time', '@modelcontextprotocol/server-filesystem', 'https://api.example.com/mcp'."

addedInput schema / properties / source / description

Added value: +"Registry/install source preference. 'auto' picks the best available; 'local' forces npx/uvx install (downloads + runs locally); 'smithery' requires SMITHERY_API_KEY; 'official' restricts to the verified MCP registry."

addedInput schema / properties / source / examples

Added value: +[
+  "auto",
+  "local",
+  "smithery",
+  "official"
+]

addedInput schema / properties / tools / description

Added value: +"Optional allowlist of tool names to mount — load only these instead of the full toolset. Use to keep context lean when a server exposes many tools you don't need."

6 tool updatesv0.20.1May 14, 2026
- First observedauth
- First observedauto
- First observedcall
- First observedsearch
- First observedshapeshift
- First observedstatus

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: authentication, automated discovery+invocation, direct invocation, server discovery, mounting, and status display. No overlap or ambiguity.

Naming Consistency5/5

All tool names are single words, lowercase, following a consistent pattern. Despite mixed verb/noun types, the naming is predictable and uniform.

Tool Count5/5

Six tools cover the essential operations for managing MCP servers: auth, search, mount, call, auto, and status. The count is well-scoped without being excessive or insufficient.

Completeness4/5

The set covers core workflows, but the search tool references an 'inspect()' function that is not provided, indicating a minor gap. Otherwise, auth, search, shapeshift, call, auto, and status form a complete lifecycle.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Library A
io.github.Spacemandomains
Search and discover 25,000+ MCP servers across all major registries. Connect and pay autonomously.
Search Developer Tools
42
Nexlab MCPOAuth
net.nexlab
28 MCP servers behind one endpoint: earth, sky, policy, records and research
1
Arclan MCP Registry A
ai.arclan
MCP server registry — validated by live handshake, scored on reliability, monitored continuously.
Developer Tools
42
MCP Registry Server A
ai.com.mcp
Publish and discover MCP servers via the official MCP Registry. Powered by HAPI MCP server.
Developer Tools Search
336,314

Related MCP Servers

Dynamic Form MCP
Developer Tools App Automation
backsoul
F
license
A
quality
D
maintenance
A server that implements the Model Context Protocol for managing dynamic forms, allowing users to create, retrieve, and handle responses for web forms via the @dynamicfrm/js library.
Updated a year ago (2025-04-22 04:24 UTC)
4
-
mcphub
Agent Orchestration Cloud Platforms Coding Agents
samanhappy
A
license
Not graded
quality
A
maintenance
A unified hub for centrally managing and dynamically orchestrating multiple MCP servers/APIs into separate endpoints with flexible routing strategies.
Updated 19 hours ago (2026-09-05 14:44 UTC)
716
2,371
Apache 2.0
mcp-proxy
Command Line Code Execution
sokunmin
F
license
B
quality
F
maintenance
mcp proxy
Updated 2 months ago (2026-07-13 09:13 UTC)
1
1
-
All-in-MCP
Research & Data Search Developer Tools
isomoes
A
license
C
quality
C
maintenance
Enables academic research through paper search across multiple databases (IACR, CryptoBib, Crossref, Google Scholar), PDF processing, and GitHub repository browsing. Features modular architecture with FastMCP-based proxy server routing to specialized academic tools.
Updated 7 months ago (2026-02-07 15:18 UTC)
7
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kaiser-data/kitsune-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Contents

Installation

Quick start

Developing an MCP server live

How it works

Tool reference

Server sources

Safety model

What it protects against

What it does NOT do

GATEWAY: consolidate always-on servers

Performance

Connection latency (what you feel)

Token overhead (secondary)

Configuration

Env and .env

Tool surface

State directory

Sandbox / trust policy

Smithery

Mount patterns

For MCP developers

Why Kitsune?

Contributing

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Env and `.env`