AI Switch MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but continue_task and generate_handoff both produce handoff/resume prompts, and append_progress overlaps with update_session. However, descriptions clarify the use cases, so ambiguity is minimal.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case (e.g., start_session, get_latest_session, delete_session). The naming is highly predictable and uniform.
Tool Count5/5
11 tools is well within the ideal 3-15 range. Each tool covers a distinct aspect of session management—create, read, update, delete, resume, and handoff—without unnecessary bloat.
Completeness5/5
The tool set provides full lifecycle coverage for cross-assistant coding sessions: start, retrieve (single, latest, list), update (append, patch), complete, and delete, along with resume and handoff helpers. No critical ops are missing.
Average 3.4/5 across 11 of 11 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
Add a glama.json file to provide metadata about your server.
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.
Add related servers to improve discoverability.

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 carries the full burden of behavioral disclosure. It indicates the tool modifies an existing session by appending progress, but it does not specify side effects, error handling, requirements like session existence, or any other behavioral traits.
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 a single, concise sentence with no wasted words, front-loaded with the verb 'Append'. It is appropriately sized for stating the core purpose, though it sacrifices detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no annotations, and no output schema, the description is far too brief to provide adequate context. It omits parameter meanings, return values, and behavioral details, leaving the agent with insufficient guidance for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/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 for explaining parameters. It does not explain any of the 7 parameters, only vaguely referencing 'progress update' and 'active assistant' without mapping to specific fields like summary, assistant, or session_id.
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 action (append), the resource (a progress update), and the target (an existing session), while specifying the source (active assistant). This distinguishes it from sibling tools like start_session and complete_session, though it does not explicitly contrast with update_session.
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 the tool should be used when an assistant needs to log a progress update to an already-created session. It does not explicitly state when to avoid using it or mention alternative tools for session updates, but the context is clear enough for basic usage.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions marking completed and appending notes, but fails to disclose side effects like whether the session becomes read-only, idempotency, or what happens if the session is already completed. This is a significant transparency gap for a mutation tool.
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 a single sentence, immediately front-loaded with the main action. It earns its place with no filler or redundancy. Perfectly concise.
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 has 4 parameters, no output schema, no annotations, and several sibling tools, the description is far from adequate. It does not explain return values, error conditions, prerequisites, or the overall session lifecycle. The context is too sparse for an agent to use this effectively.
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?
Schema description coverage is 0%, so the description must compensate. It vaguely mentions 'final summary/notes' but does not clarify the distinction between final_notes and completion_summary, nor explain the assistant parameter. The parameter names provide some self-evident meaning, but the description adds little beyond what the schema already implies.
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 function: marking a session completed and optionally appending final summary or notes. It uses a specific verb ('mark') and resource ('session'), and the 'completed' qualifier distinguishes it from siblings like start_session or append_progress. However, it doesn't explicitly contrast with update_session, so it's not fully differentiated.
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 tool versus alternatives such as update_session or append_progress. The phrase 'optionally append final summary/notes' hints at a workflow step, but it doesn't clarify prerequisites, whether the session must be in progress, or exclusions. No alternatives are mentioned.
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?
With no annotations, the description carries the full burden. It mentions the output type (markdown) and source ('from a session'), but does not disclose whether the operation is read-only, how it handles session data, or what a 'handoff and resume prompt' exactly includes. Limited behavioral insight beyond the basic function.
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 a single, concise sentence that immediately conveys the core purpose. No superfluous words or repetition, making it easy to parse.
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 four parameters, no annotations, and no output schema, the description is too sparse to provide complete guidance. It lacks parameter roles, example use cases, and output format details, leaving significant gaps for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the four parameters (session_id, project_path, target_assistant, include_completed). With 0% schema description coverage, the agent has no guidance on what values to provide or how parameters affect the output.
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 verb 'Generate' and the specific resource: 'a portable markdown handoff and resume prompt'. It uniquely identifies the tool's function, distinguishing it from sibling CRUD tools like get_session or continue_task.
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?
The description implies use when a handoff/resume prompt is needed, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. No comparison to sibling tools is provided.
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?
With no annotations provided, the description carries the full burden for behavioral transparency. It reveals that this is a patch operation (implying partial updates), but it does not disclose side effects, idempotency, permission requirements, or what the response looks like. It also does not clarify behaviors like the difference between notes_append and notes_replace.
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 a single, front-loaded sentence that quickly states the tool's purpose. It is not verbose, but it omits important usage and behavioral information that would improve its utility. Still, for what it communicates, it is concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (13 parameters), no annotations, and no output schema, this description is grossly insufficient. It provides no information about parameter details, return values, or edge cases. The agent would be forced to rely solely on parameter names and enums, which is inadequate for correct invocation.
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?
Schema description coverage is 0%, and the description must compensate for 13 parameters. It vaguely references 'metadata, task state, notes, status, and optional progress details,' which maps loosely to several parameters but does not explain any specific parameter's meaning or interdependencies. A 2 reflects minimal value added beyond the schema's bare parameter names.
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 uses the specific verb 'Patch' and clearly identifies the resource (session) along with the scope of changes: metadata, task state, notes, status, and optional progress details. This distinguishes it from siblings like append_progress (which appends progress) and complete_session (which changes status to completed).
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?
The description does not mention when to use this tool versus alternatives. There is no guidance on when to prefer update_session over append_progress or complete_session, nor does it mention any exclusions or prerequisites. Sibling tool names are visible only in context signals, not in the description.
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 provided, so description carries full burden. It only says 'create' and 'new,' implying a fresh session, but doesn't disclose side effects, whether existing sessions are affected, authentication requirements, or return behavior. This is minimal.
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 a single concise sentence with no fluff, front-loading the primary action. It is appropriately brief but sacrifices information content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 11 parameters and no output schema or annotations, yet the description provides no parameter context, prerequisites, or relationship to sibling tools. It is inadequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 27% (3 of 11 parameters have descriptions). The description adds no parameter semantics, failing to explain required fields like project_path and task or optional fields like next_steps and source_assistant.
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 uses a specific verb ('Create') and resource ('cross-assistant coding session') and adds purpose ('for resumable handoff context'). It clearly distinguishes from sibling tools focused on updating, continuing, or retrieving sessions.
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?
No explicit guidance on when to use this vs. alternatives such as continue_task or update_session. The description implies usage for starting a new session but doesn't state exclusions or alternatives.
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 clearly indicates a read operation ('Get') and an optional scoping behavior, but it does not disclose edge cases (e.g., behavior when no sessions exist), return format, or any permission requirements. Since there are no annotations, the description carries the full transparency burden but leaves these aspects unaddressed.
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 a single, well-structured sentence. It front-loads the action and resource, includes an optional modifier, and contains no unnecessary words or repetition.
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?
The tool has 4 parameters and no output schema, yet the description only covers the core retrieval action. It does not explain how the parameters affect behavior, what the return value looks like, or any constraints. This is insufficient for an agent to use the tool correctly without additional information.
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 schema description coverage at 0%, the description must compensate for the lack of parameter documentation. It only hints at 'project_path' via the phrase 'optionally scoped by project path.' The other three parameters (include_handoff, target_assistant, include_completed) are not mentioned at all, leaving their meanings undefined.
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 uses a specific verb 'Get' with a clear resource 'session' and a defining qualifier ('most recently updated'). This clearly distinguishes it from get_session (which targets a specific session) and list_sessions (which lists multiple sessions), and the optional project path scope adds further precision.
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 usage for retrieving the latest session and mentions optional scoping, but it does not explicitly state when to choose this tool over alternatives like get_session or list_sessions, nor does it provide any exclusions or prerequisites. The guidance is implicit rather than explicit.
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 discloses that it auto-selects a session and returns a prompt, which is useful. Since annotations are absent, the description must carry the transparency burden, but it does not mention side effects, failure modes, or prerequisites, leaving gaps.
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 concise and front-loaded: two sentences that start with the trigger and then the action. No wasted words; every sentence earns its place.
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?
For a tool with 7 parameters, no annotations, and no output schema, this description is too brief. It does not explain the auto-selection logic, parameter interactions, or what the 'ready continuation prompt' contains, leaving the agent under-informed.
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?
Schema description coverage is only 57%, and the description itself adds no parameter-level detail. It does not explain the three undocumented parameters (include_completed, prefer_current_directory, append_context_loaded_note) or clarify how user_request maps to the 'continue' scenario.
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 when to use the tool ('when a user says continue/resume a feature') and what it does ('Auto-selects the best session and returns a ready continuation prompt'). This distinguishes it from sibling tools like get_session or start_session.
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 gives an explicit trigger for use ('when a user says continue/resume a feature'), which is clear. However, it does not explicitly mention when not to use it or name alternative tools, though the auto-selection behavior implicitly differentiates it from related siblings.
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 fully disclose behavioral traits. It mentions the confirm=true guard to prevent accidental deletion, which is useful, but it fails to state that deletion is permanent, irreversible, or any potential side effects—a critical omission for a destructive operation.
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 concise, front-loaded sentences with no filler. The action and safety requirement are stated efficiently, making every word purposeful.
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?
Given the tool's simplicity (2 params, no output schema), the description covers the core action and safety mechanism. However, it omits details about permanence/reversibility and return behavior, making it minimally adequate but not comprehensive.
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?
The description adds value by explaining that confirm=true is required to prevent accidental deletion, which goes beyond the schema's type/default. However, session_id is only referenced as 'by ID' and not elaborated; with 0% schema description coverage, this partial compensation is moderate.
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 specific verb 'Delete' and the resource 'saved session' with the method 'by ID'. It distinguishes itself from sibling tools like update_session and get_session, making the purpose unambiguous.
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 context of use is clear: when you need to delete a saved session. It doesn't explicitly mention alternatives or exclusions, but the delete intent is straightforward, so it provides clear context without unnecessary caveats.
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 carry the full burden. It does not disclose whether the operation is read-only, what 'recent' means, how results are ordered, or any side effects. The description is a bare function statement.
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 a single concise sentence, front-loaded with the action and resource, and contains no fluff or repetition.
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?
For a simple list tool with three parameters, the description covers the core filtering function but leaves gaps: the limit parameter is not explained, no return format is mentioned (no output schema exists), and 'recent' is undefined. It is adequate but not 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 description coverage is 0%, so the description must compensate. It names project_path and status as filters, adding meaning beyond the schema, but it does not explain the limit parameter or its role in controlling result size.
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 uses the specific verb 'list' with the resource 'sessions' and mentions filters, immediately distinguishing it from siblings like get_session and get_latest_session. It clearly indicates this is a multi-session listing operation.
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 implies usage for browsing multiple sessions with optional filters, which is clear in context. However, it does not explicitly state when not to use it or name alternatives, so it falls short of a 5.
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 carries full burden. 'Fetch' implies a read operation, and it adds context about optional markdown handoff and resume prompt. However, it does not disclose permissions, error behavior, or whether the handoff is freshly generated or stored.
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?
Single sentence, front-loaded, no wasted words.
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?
For a simple fetch tool with no output schema, the description covers the essential action and optional behavior. It doesn't explain what the markdown handoff or resume prompt are, but the core use is clear. Slightly more detail on those concepts would improve it.
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 provides some mapping: 'by ID' for session_id and 'optional markdown handoff and resume prompt' for include_handoff/target_assistant, but it does not explicitly describe each parameter's value format or 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 uses the specific verb 'Fetch' with resource 'one session by ID', clearly distinguishing it from sibling tools like list_sessions and get_latest_session. It also notes optional markdown handoff and resume prompt, which defines its unique scope.
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 conveys clear context for when to use (fetching a specific session by ID) but does not explicitly mention alternatives or exclusions. It implies 'use this when you need exactly one session by ID' without naming sibling tools.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It indicates a read-like operation ('Show') and adds useful context about the shared history mechanism. It does not describe output format or error conditions, but that is acceptable for a simple zero-parameter info tool.
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 a single, concise sentence that front-loads the main action ('Show the active storage file path') and adds a brief rationale. Every word earns its place, with no redundant or vague wording.
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?
This is a low-complexity tool with no parameters and no output schema. The description provides the core purpose and enough context for an AI agent to understand when to invoke it. It could theoretically mention the return format, but 'Show the active storage file path' adequately implies the output.
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?
The tool has zero parameters, so the schema is empty and schema description coverage is 100%. Per the scoring baseline, no additional parameter explanation is needed. The description focuses on the tool's purpose rather than parameters, which is appropriate.
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 function with a specific verb ('Show') and resource ('active storage file path'), and explains its purpose ('so different MCP clients share the same history'). It is distinct from sibling tools, which focus on session operations rather than storage path inspection.
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 clear context for when to use this tool: when you need to verify that different MCP clients share the same history by checking the active storage file path. It does not explicitly mention alternatives or exclusions, but the purpose statement makes the usage scenario obvious.
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

AI Switch MCP Server MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![AI Switch MCP Server MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/Alex-Shirazi1/AISwitchMCPServer/badges/card.svg)](https://glama.ai/mcp/servers/Alex-Shirazi1/AISwitchMCPServer)

Score Badge

Copy to your README.md:

[![AI Switch MCP Server MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/Alex-Shirazi1/AISwitchMCPServer/badges/score.svg)](https://glama.ai/mcp/servers/Alex-Shirazi1/AISwitchMCPServer)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![AI Switch MCP Server MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2FAlex-Shirazi1%2FAISwitchMCPServer%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/Alex-Shirazi1/AISwitchMCPServer)

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/Alex-Shirazi1/AISwitchMCPServer'

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