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

Annotations mark this as a write (readOnlyHint=false, destructiveHint=false) and the description adds a real prerequisite the annotations don't carry: the owner's sign-in is required. It does not disclose whether submitted rows merge with or overwrite existing facts, how duplicates are handled, or what happens on validation failure at the stated caps (2000 rooms / 5000 stays).

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 short sentences, front-loaded with what the payload is before the operational notes. Minimal waste, though the sentence fragments read slightly clipped and the auth note is buried last when it affects whether the call can succeed at all.

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?

For a mutation tool with no output schema and only a non-destructive hint, the description covers the precondition (sign-in) and processing model (same rules as a report) but leaves out outcome semantics, dedupe behavior, and error handling. Adequate to attempt a call, not enough to predict what it does to existing data.

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?

Neither top-level parameter 'rooms' nor 'stays' has a schema description (coverage 0%), so the description must carry the load. 'As rows' is the only hint; it does not explain the shape of a room row vs a stay row, that both are optional, or what subset semantics apply when only one is sent.

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 names the specific resource ('Rooms and stays you already extracted, as rows') and implicitly contrasts with 'an uploaded report', so an agent can distinguish it from upload_report. The verb is only carried by the tool name/title ('Send'), not stated outright in the description body.

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 implies the use case: you have extracted rows in hand rather than a file, and guest Logic applies them like an uploaded report. It does not explicitly say when to prefer this over confirm_facts, load_stays, or upload_report, nor what to do if only rooms or only stays are known.

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