new_sessionStarts fresh session context and returns a new session_id. Reuse that ID on subsequent calls for continuity; changing or omitting it starts clean context.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | ||
| session_id | No | ||
| instructions | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Starts fresh session context and returns a new session_id,' implying a state-creating action. However, annotations declare readOnlyHint: true, which indicates the tool does not modify state. This is a direct contradiction: starting a session is a mutating action, not read-only. The description does not reconcile this conflict, so an agent could be misled about the tool's side effects.
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 only two sentences, with the primary action front-loaded and the usage guidance following immediately. Every sentence adds value: the first states what the tool does, and the second explains how to use subsequent calls. No unnecessary words or repetition.
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?
Given the tool has no parameters, an output schema (not shown), and annotations covering idempotency and destructiveness, the description adequately explains its operation and the returned session_id. It could theoretically mention persistence or lifespan, but the core information needed to call it is present. The contradiction with readOnlyHint is addressed separately and doesn't affect completeness here.
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?
The tool has zero parameters, and the schema correctly reflects that (coverage 100%). Per the rubric, a tool with no parameters receives a baseline of 4. The description adds no parameter details because none exist, but it appropriately explains the session_id output, which is not a parameter.
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 clearly states the tool's action ('Starts fresh session context') and its output ('returns a new session_id'). It is specific and distinct from sibling tools, which all have other purposes. No ambiguity exists about what this tool does.
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?
The description provides clear guidance on how to use the tool: reuse the returned session_id for continuity, and changing or omitting it starts clean context. While it does not explicitly name alternatives, this tool's purpose is unique among siblings, and the usage context is self-evident. It does not state exclusions, so it fits the 'clear context, no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.