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

Annotations already cover read-only and non-destructive behavior, so the description adds value by disclosing the required auth token ('Requires NOMADSTAYS_MCP_AGENT_TOKEN') and enumerating the exact return fields, which is especially important given no output schema. It also reveals the sequencing dependency (before updateStayContacts). It does not contradict annotations. Slight deduction for not mentioning rate limits or error conditions, but overall strong.

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?

Three concise sentences: purpose with return fields, usage context relative to updateStayContacts, and auth requirement. Each sentence serves a distinct purpose. It is front-loaded with the main action and not padded with filler. Despite the long enumeration in the first sentence, it is information-dense and well-structured.

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 there is no output schema, the description fully enumerates the expected return fields, which is essential for the agent to know what this tool provides. It also includes the auth requirement and sequencing with updateStayContacts, making it self-contained for the agent's decision-making. No additional information is needed for typical use.

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 input schema covers 100% of parameters: stayId is described as 'The Stay's EntryID (use getMyStays to find it)'. The description itself does not add any additional parameter-specific meaning; it focuses on the return value instead. Per the rubric baseline of 3 for high schema coverage, this is appropriate.

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 states a specific verb 'Get' plus a distinct resource: a Stay's contact/owner/manager details and social media links. It enumerates the exact fields (owner/manager name/email/mobile, booking email/phone/mobile, website/social links), which clearly differentiates it from generic getMyStayDetail. The explicit reference to updateStayContacts further clarifies its role.

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?

Description gives explicit usage guidance: 'Call this before updateStayContacts so the agent knows current values.' This tells the agent when to invoke this tool relative to a sibling and provides a rationale. It clearly implies this is the precursor read for contacts before making updates, which is the primary use case.

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