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

With no annotations, the description does meaningful work: auth prerequisite (owner-granted, off by default), cost profile ('Free; no spending or payouts'), and account scoping. However, it never confirms this is read-only or describes what a call returns, leaving the core behavioral trait implicit.

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?

Four short sentences with no filler, but the leading sentence is jargon-heavy ('Private Kettle of Two invitations and cups') and front-loads domain flavor rather than the tool's function, so the actionable content sits late.

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?

This is a simple status tool with no output schema and no annotations, so the description is the only source of truth about results — and it never says what the status contains (invitations? cups? membership?). The permission and cost notes are good, but the return-side gap is significant for a status endpoint.

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?

Zero parameters and 100% schema coverage, so there is nothing for the description to disambiguate; the baseline for a no-param tool applies.

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 characterizes the 'Kettle of Two' domain and its scope ('invitations and cups for your account only'), but never states the actual action — that this returns the current status/state of your kettle. An agent can infer a read from the name, but the text itself never says what the 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?

It gives real usage gating: a separate owner-granted kettle permission, off by default, and explicit exclusions ('Agents cannot start kettles or send invitations'). That rules out write/initiate use, but it never says 'call this to view your kettle' or points to a sibling like kettle_join for the actions it excludes.

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