kitsune-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.21.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.
Average 4.1/5 across 6 of 6 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 6 of 6 community issues answered or closed in the last 6 months
- 24 commits in the last 12 weeks
- Last stable release on July 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![kitsune-mcp MCP server](https://glama.ai/mcp/servers/kaiser-data/kitsune-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kaiser-data/kitsune-mcp)

Score Badge

Copy to your README.md:

[![kitsune-mcp MCP server](https://glama.ai/mcp/servers/kaiser-data/kitsune-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kaiser-data/kitsune-mcp)

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