Skip to main content
Glama
Sign In
mcp-guide

mcp-guide

by deeprave
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Switch Project

switch_project

Selects the active configuration project or rebinds the project root to an absolute path, updating the current project context.

Instructions

Switch active configuration project or rebind the project root with path.

Arguments

  • session_id: string | null

    • Opaque Guide interaction identifier returned by set_project. Pass it through unchanged on later tool, prompt, and resource calls. Do not construct, alter, or treat it as a FastMCP transport session id.

  • name: string | null

    • Configuration project name to select at the current root

  • path: string | null

    • Project root to rebind instead of selecting a configuration name. Use an absolute client path; relative paths, ~, ~user and environment expansion require verified stdio filesystem sharing. HTTP/HTTPS permits absolute paths only.

  • verbose: boolean

    • If True, return full project details; if False, return confirmation

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "args": "<args>"
    },
    "name": "switch_project"
  }
}

Input Schema

NameRequiredDescriptionDefault
argsYesArguments for selecting a configuration or rebinding the project root.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.0

TDQS

B3.3/5.0
Behavior3/5

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

No annotations exist, so the description carries the whole burden. It does disclose real behavior — that path rebinding has different resolution rules than name selection, and that session_id is an opaque token that must be passed through unchanged and not treated as a transport session id — but says nothing about reversibility, what happens to the previously active project, or failure modes for unknown names.

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

Conciseness3/5

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

The purpose line is front-loaded and useful, but more than half the text is an Arguments block that duplicates the input schema field-for-field. The parameter documentation would earn its place only if it added guidance the schema lacks; as written it is redundancy.

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 two-mode switching tool with no annotations and no output schema, the definition covers the mode split, path resolution limits, and the verbose-controlled return shape. It leaves open the interaction with set_project and the behavior on invalid name/path, so 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 100%, so the baseline is 3. The Arguments section reproduces the schema descriptions nearly verbatim, adding no syntax examples or interaction detail beyond what the schema already states.

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?

Opens with a specific verb and resource: 'Switch active configuration project or rebind the project root with path.' An agent immediately knows the two operating modes. It stops short of a 5 because it never differentiates itself from the sibling set_project, which it references only as the producer of session_id.

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?

Usage is implied through the mutually exclusive name/path modes and the schema's oneOf, plus concrete path constraints (absolute client paths; relative/~ require verified stdio filesystem sharing; HTTP/HTTPS permits absolute only). There is no explicit when-to-use versus set_project or guidance on error conditions.

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

Deploy Server

Other Tools