daemon_info

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 clearly frames the tool as a read-only metadata/report operation, and it adds valuable nuance such as the serve-proxy binary not being updated by daemon restart and the caution to check it before concluding a proxy-side fix is live. It also discloses conditional output like the workspace-pin provenance and protocol mismatch details.

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 dense and runs on as one long sentence, but every clause carries meaningful information about return fields and edge cases. The core purpose is front-loaded, and although a structured list would improve readability, the content is not wasteful.

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 that there is no output schema and no annotations, the description is remarkably complete: it covers the purpose, the full set of returned metadata fields, important version nuances, configuration state, and even usage intent. An agent has enough context to decide when to call this tool and what to expect from it.

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, so the baseline is 4. There is no parameter information to add beyond the empty schema, and the description appropriately focuses on what the tool returns rather than inventing parameter guidance.

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 opens with a specific action ('Returns metadata about the current MCP session and daemon process') and enumerates exactly what the tool provides. It clearly distinguishes daemon_info from session-management siblings by focusing on daemon/session introspection rather than session mutation or workspace operations.

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 explicitly states when to use the tool: 'Use this to identify which session you are operating in or to verify the daemon state.' It provides clear context but does not name alternatives or when-not-to-use cases, so it falls just short of full exclusionary guidance.

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