de en es ja ko ru zh

kitsune-mcp

Name: kitsune-mcp
Author: kaiser-data

by kaiser-data

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

PyPI npm MCP Registry Python Coverage License: MIT Smithery Discord

What's new in v0.9.0

Friction-reduction release focused on first-run onboarding, credential visibility, and agent workflows.

search() shows credential status per result — ✅ ready or ✗ needs BRAVE_API_KEY inline, so you know before you shapeshift
shapeshift(server_id, source="local", confirm=True) — force a local npx/uvx install without a Smithery key; source="smithery" forces HTTP; source="official" requires a verified registry listing
shiftback(uninstall=True) — optionally removes the locally installed package (uvx fully removed via uv tool uninstall; npx cache clears automatically)
KITSUNE_TRUST=community env var — skip the confirm=True gate permanently for trusted users and agents; set once via key("KITSUNE_TRUST", "community")
First-run onboarding in status() — clean sessions now show a 5-step getting-started guide with an example flow
Lean-mounting hint — after a heavy shapeshift() the output suggests tools=[...] with a concrete tool name and token cost
Registry failure reporting — search() now shows ⚠️ Skipped: <name> (timeout) when one registry is slow, so you know results are partial instead of silently incomplete

See CHANGELOG.md for the full list plus internal refactors and bug fixes.

Related MCP server: mcphub

Why Kitsune?

In Japanese folklore, the Kitsune (狐) is a fox spirit of extraordinary intelligence and magical power. What makes it remarkable is how it grows: with age and wisdom, a Kitsune gains additional tails — each one representing a new ability it has mastered. It can shapeshift, take on any form it chooses, borrow the powers of others, and just as freely cast them off when the purpose is fulfilled. One fox. Many forms. Total fluidity.

This tool works the same way.

shapeshift("brave-search") — the fox takes on a new form, its tools appear natively. shiftback() — it returns to its true shape, ready to become something else.

Each server it shapeshifts into is a new tail. Each capability borrowed and released cleanly. One entry in your config. Every server in the MCP ecosystem, on demand.

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 — a spirit that shapeshifts between forms, gains new powers, and releases them at will. That is exactly what this tool does.

The problem with static MCP setups

Every server you add to your config loads all its tools at startup — and keeps them there, all session long. Whether your agent uses them or not.

Five servers means 3,000–5,000 tokens of overhead on every request. Your agent sees 50+ tools and has to reason about all of them before it can act.

Kitsune MCP is one entry that replaces all of them.

shapeshift("brave-search", tools=["web_search"])  # only the tool you need
# task done — switch instantly:
shiftback()
shapeshift("supabase")                            # different server, no restart
shiftback()
shapeshift("@modelcontextprotocol/server-github") # and again

One config entry. Any server across 7 registries. Load only the tools the current task needs — 2 out of 20 if that's all you need. Your agent stays focused and your costs stay low.

Base overhead: 7 tools, ~650 tokens (measured). Each mounted server adds only what you actually load.

Built for two audiences

Adaptive agents

An agent that loads everything upfront burns tokens on tools it never calls — and makes worse decisions because it sees too many options at once. An agent that mounts on demand is leaner, faster, and more focused:

Shapeshift into only what the current task needs — shiftback when done
shapeshift(server_id, tools=[...]) to cherry-pick — load 2 tools from a server that has 20
Chain across multiple servers in one session without touching config or restarting
Token overhead stays flat: ~650 base + only what you load

Kitsune MCP is designed around the real economics of an agent loop.

MCP developers

Beyond MCP Inspector's basic schema viewer, Kitsune MCP gives you a full development workflow inside your actual AI client:

Need	Tool
Explore a server's tools and schemas	`inspect(server_id)`
Quality-score your server end-to-end	`test(server_id)` → score 0–100
Benchmark tool latency	`bench(server_id, tool, args)` → p50, p95, min, max
Prototype endpoint-backed tools live	`craft(name, description, params, url)`
Test inside real Claude/Cursor workflows	`shapeshift()` → call tools natively → `shiftback()`
Compare two servers side by side	shapeshift into one, test, shiftback, shapeshift into the other

No separate web UI. No isolated test environment. Test how your server actually behaves when an AI uses it.

Two modes

	`kitsune-mcp`	`kitsune-forge`
Purpose	Adaptive agents, everyday mounting	MCP evaluation, benchmarking, crafting
Tools	7 (shapeshift, shiftback, search, inspect, call, key, status)	All 17
Token overhead	~650 tokens	~1,700 tokens
Use when	Agents mounting per task, minimal token budget	Discovering, testing, benchmarking, prototyping

Token numbers are measured from actual registered schemas — see examples/benchmark.py.

Both modes from the same package:

{ "command": "kitsune-mcp" }                        ← lean (default)
{ "command": "kitsune-forge" }                      ← full suite
{ "command": "kitsune-mcp",
  "env": { "KITSUNE_TOOLS": "shapeshift,shiftback,key" } }  ← custom

How It Fits Together

shapeshift() injects tools directly at runtime via FastMCP's live API. Token overhead stays flat regardless of how many servers you explore.

Need the full evaluation suite? kitsune-forge adds execution, connection management, benchmarking, and tool crafting:

Quick Start

pip install kitsune-mcp

Add to your MCP client config — once, globally:

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

Works with Claude Desktop, Claude Code, Cursor, Cline, OpenClaw, Continue.dev, Zed, and any MCP-compatible client. No API keys needed.

Client	Global 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`
OpenClaw	MCP config in OpenClaw settings

Server Sources

Kitsune MCP searches across 7 registries in parallel — tens of thousands of servers, no single one required.

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

Default search() fans out across all no-auth registries automatically. Add a SMITHERY_API_KEY to extend discovery with Smithery's hosted server catalog (HTTP servers, no local install required).

How It Works

The proxy model

Kitsune MCP is a dynamic MCP proxy. It sits between your AI client and any number of other MCP servers, connecting to them on demand:

Your AI client
    │
    ▼
Kitsune MCP          ← the one entry in your config
    │
    ├── (on shapeshift) ──► filesystem server   (spawned subprocess)
    ├── (on shapeshift) ──► brave-search server (spawned subprocess)
    └── (on shapeshift) ──► remote HTTP server  (HTTP+SSE connection)

Nothing is copied. When you call a mounted tool, Kitsune MCP forwards the call to the original server via JSON-RPC and returns the result. The server's logic always runs on the server — Kitsune MCP only relays the schema and the call.

What shapeshift() does, step by step

Connects to the target server via the right transport (stdio subprocess, HTTP, WebSocket)
Handshakes — sends MCP initialize / notifications/initialized
Fetches tools/list, resources/list, prompts/list from the server
Registers each tool as a native FastMCP tool — a proxy closure with the exact signature from the schema
Notifies the AI client (notifications/tools/list_changed) so the new tools appear immediately

The AI sees read_file, write_file, list_directory as if they were always there. There's no wrapper or call_tool("filesystem", ...) indirection — the tools are first-class.

shiftback() reverses all of it: deregisters the proxy closures, clears resources and prompts, notifies the client.

Resources and prompts

shapeshift() proxies all three MCP primitives, not just tools:

Primitive	What gets proxied
Tools	Every tool from `tools/list`, registered with its exact parameter schema
Resources	Static resources from `resources/list` — readable via the MCP resources API
Prompts	Every prompt from `prompts/list`, with its argument signature

Template URIs (e.g. file:///{path}) are skipped — they require parameter binding that adds complexity with little practical gain. Everything else is proxied.

Transport is automatic

Server source	How it runs
npm package	`npx <package>` — spawned locally
pip package	`uvx <package>` — spawned locally
GitHub repo	`npx github:user/repo` or `uvx --from git+https://...`
Docker image	`docker run --rm -i --memory 512m <image>`
Smithery hosted	HTTP+SSE (requires `SMITHERY_API_KEY`)
WebSocket server	`ws://` / `wss://`

Why inspect() before shapeshift()

inspect() connects to the server and fetches its schemas — but does not register anything. Zero tools added to context, zero tokens consumed by the AI.

Use it to:

See exact parameter names and types before committing
Check credential requirements upfront (avoid a cryptic error mid-task)
Get the measured token cost of the mount so you can budget
Verify the server actually starts and responds before a live session

inspect("mcp-server-brave-search")
# → CREDENTIALS
# →   ✗ missing  BRAVE_API_KEY — Brave Search API key
# →   Add to .env:  BRAVE_API_KEY=your-value
# → Token cost: ~99 tokens (measured)

# Add the key to .env — picked up immediately, no restart needed
# Then mount and use in the same session:
shapeshift("mcp-server-brave-search")
call("brave_web_search", arguments={"query": "MCP protocol 2025"})

Security

Kitsune MCP introduces a trust model for servers you haven't personally audited.

Trust tiers

Every shapeshift(), call(), and connect() result shows where the server comes from:

Tier	Sources	Indicator
High	`official` (modelcontextprotocol/servers)	`✓ Source: official`
Medium	`mcpregistry`, `glama`, `smithery`	`✓ Source: smithery`
Community	`npm`, `pypi`, `github`	`⚠️ Source: npm (community — not verified)`

Community servers and source="local" installs require confirm=True — you're explicitly acknowledging you've reviewed the server before running arbitrary code. To bypass this for servers you already trust, set KITSUNE_TRUST=community (via key("KITSUNE_TRUST", "community") or your .env). This persists across sessions so power users and agents never see the gate again.

Install command validation

Before spawning any subprocess, Kitsune MCP validates the executable name:

Blocks shell metacharacters (&, ;, |, `, $) — prevents injection via a crafted server ID
Blocks path traversal (../) — prevents escaping to arbitrary binaries

Arguments are passed directly to asyncio.create_subprocess_exec (never a shell), so they are not subject to shell interpretation.

Credential warnings

shapeshift() probes tool descriptions for unreferenced environment variable patterns. If a tool mentions BRAVE_API_KEY and that variable isn't set, you get a warning immediately — before you call anything:

⚠️  Credentials may be required — add to .env:
  BRAVE_API_KEY=your-value
  Or: key("BRAVE_API_KEY", "your-value")

Process isolation and sandboxing

stdio servers run as separate OS processes — no shared memory with Kitsune MCP
Docker servers run with --rm -i --memory 512m --label kitsune-mcp=1
fetch() blocks private IPs, loopback, and non-HTTPS URLs (SSRF protection)
The process pool has a hard cap of 10 concurrent processes and evicts idle ones after 1 hour

What You Can Access

One kitsune-mcp entry unlocks any of these on demand — no config changes, no restart:

Category	Servers	Key needed	Lean tokens
Web search	Brave Search, Exa, Linkup, Parallel	Free API keys	~150–993
Web scraping	Firecrawl, ScrapeGraph AI	Free tiers	~400 (lean)
Code & repos	GitHub (official, 26 tools)	Free GitHub token	~500 (lean)
Productivity	Notion, Linear, Slack	Free workspace keys	~400 (lean)
Google	Maps, Calendar, Gmail, Drive	Free GCP key / OAuth	varies
Memory	Mem0, knowledge graphs	Free tiers	~300
No key required	Filesystem, Git, weather, Yahoo Finance	—	~300–1,000

The same pattern works for all of them:

shapeshift("brave")                                    # web search in 2 tools
call("brave_web_search", arguments={"query": "…"})

shapeshift("firecrawl-mcp", tools=["scrape","search"]) # scraping, lean (2 of 9 tools)
call("scrape", arguments={"url": "https://…"})

shapeshift("@modelcontextprotocol/server-github", tools=["create_issue","search_repositories"])
call("create_issue", arguments={"owner": "…", "repo": "…", "title": "…"})

Token cost scales with what you load, not what exists. A 26-tool GitHub server costs ~500 tokens if you only mount 3 tools. See .env.example for the full key catalog with lean mount hints.

Security note on `.env`

Kitsune MCP re-reads .env on every call — which means adding a key instantly activates it. That convenience comes with a responsibility: .env is the single place all your API keys live. A few practices worth following:

Add .env to .gitignore — never commit real keys
Use project-level .env for project-specific keys; ~/.kitsune/.env for personal global keys
Prefer minimal OAuth scopes and fine-grained tokens (e.g. GitHub fine-grained tokens with per-repo permissions)
Rotate keys that get exposed; Kitsune MCP picks up the new value immediately without restart

Why Not Just X?

"Can't I just add more servers to mcp.json?" — Every configured server starts at launch and exposes all tools constantly. You can't add or remove mid-session without a restart. With 5+ servers you're burning thousands of tokens on every request for tools rarely needed. Kitsune MCP keeps the tool list minimal — shapeshift into what you need, shiftback when done.

"What about MCP Inspector?" — MCP Inspector is a standalone web UI that connects to one server and lets you inspect schemas and call tools manually. It's useful for basic debugging but isolated from real AI workflows. Kitsune MCP tests servers inside actual Claude or Cursor sessions — how an AI really uses them. It adds test() scoring, bench() latency numbers, side-by-side server comparison, and craft() for live endpoint prototyping. It also discovers and installs servers on demand; Inspector requires you to already have one running.

"What about mcp-dynamic-proxy?" — It hides tools behind call_tool("brave", "web_search", {...}) — always a wrapper. After shapeshift("mcp-server-brave-search"), Kitsune MCP gives you a real native brave_web_search with the actual schema. It also can't discover or install packages at runtime.

"Can FastMCP do this natively?"

	FastMCP native	Kitsune MCP
Proxy a known HTTP/SSE server	✅	✅
Load tools at runtime	✅ (write code)	✅ `shapeshift()`
Search registries to discover servers	❌	✅ npm · official · Glama · Smithery
Install npm / PyPI / GitHub packages on demand	❌	✅
Atomic shift back — retract all shapeshifted tools at once	❌	✅ `shiftback()`
Persistent stdio process pool	❌	✅
Zero boilerplate — works after `pip install`	❌	✅

Configuration

Minimal (no API keys)

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

Optional integrations

{
  "mcpServers": {
    "kitsune": {
      "command": "kitsune-mcp",
      "env": { "SMITHERY_API_KEY": "your-key" }
    }
  }
}

Get a free key at smithery.ai/account/api-keys. Without it, Kitsune MCP is fully functional via npm, PyPI, official registries, and GitHub.

Frictionless credentials — Kitsune MCP re-reads .env on every inspect(), shapeshift(), and call(). Add a key mid-session and it takes effect immediately — no restart:

# .env (CWD, ~/.env, or ~/.kitsune/.env — all checked, CWD wins)
BRAVE_API_KEY=your-key
GITHUB_TOKEN=ghp_...

Or use key() to write to .env and activate in one step:

key("BRAVE_API_KEY", "your-key")   # writes to .env, active immediately

All Tools

`kitsune-mcp` — lean profile (7 tools, ~650 token overhead)

Tool	Description
`shapeshift(server_id, tools, source, confirm)`	Load a server's tools live. `tools=[...]` for lean load. `source="local"` forces npx/uvx install; `source="smithery"` forces HTTP.
`shiftback(kill, uninstall)`	Remove shapeshifted tools. `kill=True` terminates the process. `uninstall=True` also removes a locally installed package.
`search(query, registry)`	Search MCP servers across registries.
`inspect(server_id)`	Show tools, schemas, and live credential status (✓/✗ per key).
`call(tool_name, server_id, args)`	Call a tool. `server_id` optional when shapeshifted — current form used.
`key(env_var, value)`	Save an API key to `.env` and load it immediately.
`status()`	Show current form, active connections (PID + RAM), token stats.

`kitsune-forge` — full suite (all 17 tools, ~1,700 token overhead)

Everything above, plus:

Tool	Description
`call(tool_name, server_id, args)`	Already in lean profile — listed here for completeness.
`run(package, tool, args)`	Run from npm/pip directly. `uvx:pkg-name` for Python.
`auto(task, tool, args)`	Search → pick best server → call in one step.
`fetch(url, intent)`	Fetch a URL, return compressed text (~17x smaller than raw HTML).
`craft(name, description, params, url)`	Register a custom tool backed by your HTTP endpoint. `shiftback()` removes it.
`connect(command, name)`	Start a persistent server. Accepts server_id or shell command.
`release(name)`	Kill a persistent connection by name.
`setup(name)`	Step-by-step setup wizard for a connected server.
`test(server_id, level)`	Quality-score a server 0–100.
`bench(server_id, tool, args)`	Benchmark tool latency — p50, p95, min, max.
`skill(qualified_name)`	Load a skill into context. Persisted across sessions.

Usage Examples

Adaptive agent — multi-server session, zero config

# Task 1: read some files
shapeshift("@modelcontextprotocol/server-filesystem", tools=["read_file"])
read_file(path="/tmp/data.csv")
shiftback()

# Task 2: search the web
shapeshift("mcp-server-brave-search")
brave_web_search(query="latest MCP servers 2025")
shiftback()

# Task 3: run a git query
shapeshift("@modelcontextprotocol/server-git", tools=["git_log"])
git_log(repo_path=".", max_count=5)
shiftback()
# Three different servers. One session. Zero config edits.

MCP developer workflow — test your server

# Evaluate your server before publishing
inspect("my-server")               # review schemas and credentials
test("my-server")                  # quality score 0–100
bench("my-server", "my_tool", {})  # p50, p95 latency

# Prototype a tool backed by your local endpoint
craft(
    name="my_tool",
    description="Calls my ranking service",
    params={"query": {"type": "string"}},
    url="http://localhost:8080/rank"
)
my_tool(query="test")   # call it natively inside Claude
shiftback()

Same-session usage with call()

After shapeshift(), use call() immediately — no restart, no server_id needed:

shapeshift("@modelcontextprotocol/server-filesystem")
# → "In this session: call('tool_name', arguments={...})"

call("list_directory", arguments={"path": "/Users/me/project"})
call("read_file", arguments={"path": "/Users/me/project/README.md"})
shiftback()

Search, shapeshift, use, shiftback

search("web search")
shapeshift("mcp-server-brave-search")
key("BRAVE_API_KEY", "your-key")   # picked up immediately
call("brave_web_search", arguments={"query": "MCP protocol 2025"})
shiftback()

Local install — no API key needed

# Force local install via npx/uvx — no Smithery key required
shapeshift("brave", source="local", confirm=True)
# → spawns npx locally, tools appear natively
call("brave_web_search", arguments={"query": "MCP 2026"})
shiftback(uninstall=True)   # remove tools AND uninstall the package

Persistent server with setup guidance

connect("uvx voice-mode", name="voice")
setup("voice")                      # shows missing env vars
key("DEEPGRAM_API_KEY", "your-key")
setup("voice")                      # confirms ready
shapeshift("voice-mode")
speak(text="Hello from Kitsune MCP!")
shiftback(kill=True)                    # terminates process, frees RAM

Installation

uvx kitsune-mcp                # recommended — uv manages the env automatically
# or
pip install kitsune-mcp        # classic pip
# or
npx kitsune-mcp                # if you prefer npm (delegates to uvx internally)

Requirements: Python 3.12+ · node/npx (for npm servers) · uvx from uv (for pip servers)

Tip: uvx kitsune-mcp is the easiest way — uv installs into an isolated env automatically. No venv setup needed.

Contributing

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

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

MIT License · Python 3.12+ · Built on FastMCP

Available Tools

9 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.

releaseB

Kill a persistent connection by name.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It does disclose the core behavioral trait, that this terminates/kills a connection (a destructive, non-reversible action), which is the most important signal. However, it omits permissions required, behavior when the name does not exist, and whether the operation is idempotent.

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, front-loaded sentence with the action first and the identifier second. Every word earns its place and there is no filler.

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

Completeness3/5

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

Because an output schema exists, return values need not be explained. For a one-parameter destructive operation, the description covers the essential action but leaves gaps around failure modes, permissions, and effects on the connection's state, which is thin for a no-annotation tool.

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% for the single 'name' parameter, so the description must compensate. 'By name' clarifies that the parameter identifies the connection to kill, adding meaning beyond the bare schema, but it does not specify naming conventions or whether the name is case-sensitive or unique.

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 gives a clear verb (kill) and resource (persistent connection), with a scoping clause ('by name'). It is specific enough for an agent to distinguish it from siblings like connect and status, though it does not name any sibling explicitly.

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?

There is no guidance on when to use this versus alternatives such as connect or reload, nor any prerequisite (e.g., that a connection must exist first). The only implied usage is inferring from 'persistent connection' that it targets an existing session.

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.

1 tool updatev0.21.1Sep 14, 2026
- Addedrelease

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

Deploy Server

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

TDQS

A3.8/5.0

Scored 2026-09-14 14:45 across 9 tools

Disambiguation4/5

Most tools have distinct roles: search discovers servers, auth handles credentials, call invokes a known tool, and auto combines discovery and invocation. However, connect/shapeshift/release/reload/status all concern server lifecycle and can overlap in when-to-use decisions, though descriptions help clarify.

Naming Consistency4/5

All names are lowercase single words with no mixed camelCase/snake_case inconsistencies. The convention is not verb_noun, and status is a noun while most others are action words, but the set is still readable and predictable enough.

Tool Count5/5

Nine tools is well-scoped for an MCP orchestration server covering discovery, auth, connection, mounting, calling, reloading, releasing, and status. Each tool appears to earn its place without excessive surface.

Completeness4/5

The core lifecycle is covered: search, auth, connect, shapeshift, call, auto, reload, release, and status. A minor gap is the referenced inspect() operation, which is mentioned in search's description but not exposed as a tool.

Maintenance

ActivityMaintained

ResponsivenessWithin a week

Resources

Need Help?

Related Servers

Related MCP Connectors

Arclan MCP Registry A
ai.arclan
MCP registry: 138k servers crawled, handshake-validated, reliability-scored. 744 production-safe.
Developer Tools
42
Library A
io.github.Spacemandomains
Search and discover 25,000+ MCP servers across all major registries. Connect and pay autonomously.
Search Developer Tools
42
MCP Registry Search: Find, Discover & Install MCP Servers & Tools | Directory, Catalog, Marketplace A
io.github.lbesecker195
MCP registry & directory: search, find & install 31k+ MCP servers & tools. Catalog and marketplace.
Developer Tools Search
311
Nexlab MCPOAuth
net.nexlab
28 MCP servers behind one endpoint: earth, sky, policy, records and research
Research & Data Government Data Open Data
1

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 a day ago (2026-10-10 03:38 UTC)
1,706 npm
2,513
Apache 2.0
mcp-proxy
Command Line Code Execution
sokunmin
F
license
B
quality
F
maintenance
mcp proxy
Updated 3 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 8 months ago (2026-02-07 15:18 UTC)
7
2
MIT

What's new in v0.9.0

Why Kitsune?

The problem with static MCP setups

Built for two audiences

Adaptive agents

MCP developers

Two modes

How It Fits Together

Quick Start

Server Sources

How It Works

The proxy model

What shapeshift() does, step by step

Resources and prompts

Transport is automatic

Why inspect() before shapeshift()

Security

Trust tiers

Install command validation

Credential warnings

Process isolation and sandboxing

What You Can Access

Security note on .env

Why Not Just X?

Configuration

Minimal (no API keys)

Optional integrations

All Tools

kitsune-mcp — lean profile (7 tools, ~650 token overhead)

kitsune-forge — full suite (all 17 tools, ~1,700 token overhead)

Usage Examples

Adaptive agent — multi-server session, zero config

MCP developer workflow — test your server

Same-session usage with call()

Search, shapeshift, use, shiftback

Local install — no API key needed

Persistent server with setup guidance

Installation

Contributing

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Security note on `.env`

`kitsune-mcp` — lean profile (7 tools, ~650 token overhead)

`kitsune-forge` — full suite (all 17 tools, ~1,700 token overhead)