emacs_project_switch

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 of behavioral disclosure. It only states 'Switch to a different project' with no information about side effects, state persistence, validation of the path, or impact on buffers/workspace. This is essentially the surface-level action with no behavioral traits beyond the tautological meaning.

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

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

The description is a single, front-loaded sentence with no filler words. It is concise and readable, though slightly under-specified. The structure is efficient for the information it conveys.

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

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

The tool has no annotations, no output schema, and relies on a single parameter. For a state-changing operation, the description does not explain what happens after switching, whether the path must already be a known project root, or how this relates to project listing/current tools. This is inadequate for safe, correct invocation without additional context.

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

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

Schema description coverage is 100%, so the parameter 'path' is already documented as 'Project root path to switch to'. The description adds no additional meaning beyond the schema, which is acceptable at the baseline score of 3.

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

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

The description uses a specific verb ('switch') and resource ('project'), clearly stating the core action. It is not a tautology, and the input schema reinforces that it changes the active project by path. However, it does not explicitly differentiate from sibling tools like emacs_workspace_switch or emacs_project_current.

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

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

No guidance is given on when to use this tool versus alternatives such as emacs_workspace_switch or emacs_project_current. The description is a bare action statement with no contextual cues, prerequisites, or exclusions, leaving the agent to infer usage entirely from the name and sibling list.

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