Eight Sleep Agent Manifest

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds minimal behavioral context beyond that—it frames the tool as providing guidance but does not describe what kind of guidance, whether it is static or dynamic, or any dependencies. It does not contradict the annotations, and the bar is lower because annotations cover the key safety traits.

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 clear sentence that front-loads the key attribute 'Machine-readable' and quickly lists the content areas: install, runtime, and client guidance. It avoids redundancy and wasted words. It could be slightly more explicit with a verb, but overall it is well-sized.

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 low complexity (2 optional enum parameters) and the presence of an output schema plus annotations, the description is mostly adequate for a simple informational manifest. However, it lacks guidance on how an agent should use this tool in a workflow—e.g., when to call it, how it relates to sibling discovery tools, or what 'operating the Eight Sleep MCP' implies. A bit more context would be needed for first-time agents.

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 0%, so the description must compensate for explaining parameters, but it does not mention client or response_format at all. The parameter names and enums are self-explanatory to some extent (client selects the AI client, response_format selects markdown vs JSON), but no guidance is provided on how to choose them or what effect they have on the returned manifest.

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 identifies the tool as a resource for install, runtime, and client guidance for AI agents working with the Eight Sleep MCP. The phrase 'Machine-readable guidance' conveys a specific purpose and differentiates it from data retrieval or mutation tools. However, it lacks a strong imperative verb like 'retrieve' or 'provide,' and it does not explicitly distinguish itself from sibling tools such as eight_sleep_capabilities.

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?

There is no guidance on when to use this tool versus alternatives like eight_sleep_capabilities or eight_sleep_connection_status. The description does not state that it is the first tool to consult for setup, or that it should not be used for runtime data. An agent would have to infer its role from the title and context.

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