Guest Logic

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

Annotations only cover the safety triad (non-read-only, non-destructive, closed-world), while the description adds genuinely useful behavior: accepted formats, a 10 MB ceiling, a rate limit of 40 per day while testing, and an authentication requirement. One mild tension exists between "public web address" and openWorldHint=false, but the tool still operates on internal booking-page state, so this is not a true contradiction.

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?

Two sentences, zero filler: target and constraints first, then operational limits and the auth requirement. Every clause carries distinct information an agent needs before calling.

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, the description covers inputs, size/format limits, quota, auth, and targeting scope. It stops short of explaining what happens to an existing cover photo when cover=true or how to remove a photo, which would round out the mutation semantics.

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 coverage is 100%, so all four parameters are already documented, and the description only echoes the room_type semantics ("the hotel, or one room type"). It adds the source constraints around url but nothing new about cover or caption, so the baseline 3 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?

States a specific verb and resource ("Adds a picture ... to the booking page") and disambiguates the two possible targets: the hotel, or one room type. The accepted formats, size cap, and source type are all named, so an agent can tell this apart from siblings like set_logo or upload_report without opening the schema.

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 gives a prerequisite ("Needs the owner's sign-in") and implies usage through the hotel-vs-room-type target split, but never says when to use this instead of set_logo, upload_report, or other media-related siblings. No explicit exclusions or alternative-routing guidance is provided.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: a 24-hour turnaround expectation and an authentication requirement tied to the owner. It does not say whether the request is queued, what happens if the owner is not signed in, or whether the request can be cancelled/duplicated.

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 the action and the alternatives, followed by turnaround and the sign-in precondition. No filler or repeated information.

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 two-parameter, no-output-schema request tool, the definition covers what the tool does, what to expect (24 hours), and what is required (owner sign-in). The one gap is that it never says how to follow up on the request afterward, which the setup_status sibling presumably handles.

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 coverage is 50%: 'note' is documented in the schema, but the 'what' enum values (cards, channels, white_glove) have no schema descriptions. The description partially compensates by unpacking each choice ('card payments', 'Expedia and Booking.com', 'finish the whole setup by hand'), which is enough for an agent to pick the right value. With half the parameters covered by the schema, a 3 is the appropriate baseline.

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 gives a specific verb and resource: it asks the human Guest Logic team to perform a connection on the owner's behalf. The three enumerated outcomes (card payments, Expedia/Booking.com channels, full hand-held setup) map cleanly onto the tool's intent and distinguish it from self-serve siblings like start_signup or setup_status, though it never names those siblings.

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?

Usage context is clear: this is the escalation path when connections must be made by the team or finished manually, and 'Needs the owner's sign-in' signals a real precondition before invoking. It stops short of explicit exclusions (e.g. 'do not use if setup_status shows already connected'), so the agent must infer the boundary itself.

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

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

Annotations already declare read-only, non-destructive, and closed-world behavior. The description adds useful context about the returned fields (when, result, error) and authentication, but omits how many runs are returned, the time window, or pagination behavior.

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?

Two short sentences, front-loaded with the resource and scope, and the auth prerequisite follows efficiently. There is no redundant or filler wording.

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 zero-parameter read-only status tool with annotations covering safety, the description supplies the key return fields and the auth requirement. It is slightly incomplete about the number of runs or time range, but no output schema exists and the core information is present.

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 takes zero parameters, so the baseline is 4. There is no parameter meaning for the description to add, and it correctly avoids inventing any.

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 a specific resource and scope: the last runs of the hotel's automations, including when, result, and error. It is distinguishable from the sibling list_automations, which presumably lists automation definitions rather than run history, though it does not explicitly say so.

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 states a prerequisite (owner sign-in) but gives no when-to-use guidance, no exclusions, and does not name an alternative tool. An agent must infer that this is the tool for checking recent automation outcomes versus list_automations for definitions.

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

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

Annotations already establish that this is a read-only, non-destructive, closed-world operation. The description adds useful behavioral context beyond annotations: the owner must be signed in and the date range cannot exceed 31 days. It still does not explain the exact return shape, such as whether results are counts per room type per night.

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 two short sentences with no wasted wording, and the core purpose is front-loaded. The second sentence adds the key constraints without burying the main point.

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 simple two-parameter read-only tool, the description covers the essential purpose, auth prerequisite, and date-range limit. It is slightly incomplete because there is no output schema and the description does not specify the return format or timezone assumptions.

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 coverage is 100%, and the schema already documents that from and to are YYYY-MM-DD dates. The description adds the 31-day range limit, which is useful, but it does not add syntax or meaning for the individual parameters beyond the schema. The phrase 'by room type' appears to describe output grouping rather than a parameter and is not clarified.

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 resource and scope: rooms free each night by room type for a date range up to 31 days. It is clear what the tool returns, but it does not explicitly distinguish itself from related siblings such as stays, stay, or house_inventory.

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?

Usage is implied by the availability purpose and by the stated constraints: owner sign-in is required and the range is capped at 31 days. However, the description does not say when to prefer this tool over related siblings or when not to use it.

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

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

Annotations declare a non-destructive, closed-world mutation, and the description adds real context beyond them: an owner sign-in requirement and the fact that several steps (rooms, ooo, people, bookings) are confirm-only rather than value-bearing. It stops short of saying whether values replace or merge existing state, or what an error looks like.

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 purpose is front-loaded and the step catalogue is packed into a single dense line with separators, so nothing is wasted. The density slightly hurts scanability, but every clause carries information the schema does not.

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 two-parameter mutation with no output schema, the description covers the auth prerequisite and the full per-step payload shape, which is most of what an agent needs. Gaps remain around return value, idempotency of confirmations, and ordering relative to submit_facts.

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 coverage is only 50% and the 'values' property just says 'see the description', so the description carries the burden and does: it maps every enum value of step to its expected fields and formats (percentages, HH:MM, CODE-keyed maps). That is exactly the meaning an agent needs to construct a valid values object.

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?

States a specific verb and resource ('Confirms or changes one setup step') and enumerates the exact step domains it operates on, so an agent knows this is the per-step write path in the setup flow. It never names the obvious sibling submit_facts or setup_status, so differentiation from siblings must be inferred.

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?

Usage is implied rather than stated: the agent can infer this is called once per setup step, and the prerequisite 'Needs the owner's sign-in' gives a useful gate. There is no explicit when-to-use versus submit_facts or setup_status, and no statement of what happens if a step is called out of order or twice.

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

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

The annotations already establish readOnlyHint=true, openWorldHint=false, and destructiveHint=false. The description adds useful auth context with 'Needs the owner's sign-in', but it does not clarify that the tool only returns links rather than performing uploads, nor does it describe link expiry or output shape.

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 compact and front-loads the owner context and auth requirement. The phrase 'and to manage photos' is vague, but overall there is little wasted wording.

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?

With zero parameters and existing annotations, the description covers the auth prerequisite and a general use case. It is still incomplete for a link-returning tool because it does not explain what kind of links are returned, whether multiple links are possible, or how this differs from sibling upload tools.

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 there is no parameter semantics burden. The description does not need to explain inputs, and the baseline for a no-parameter 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 hints that this tool returns owner-specific links for dropping files and managing photos, but it never states a clear verb or resource like 'Get upload link'. It does not explicitly distinguish the tool from siblings such as add_photo or upload_report.

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 an implied use case, 'files you cannot send as text (a scanned PDF)', which helps an agent understand when the tool is relevant. However, it provides no explicit when-not guidance and does not name alternatives for photo or report upload scenarios.

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

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds value beyond them by disclosing an authorization requirement (owner sign-in) and enumerating the categories of data returned, which matters given there is no output schema. It still omits format, size, or fallback behavior for a day with no activity.

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?

Two short sentences, front-loaded with the data scope and followed by the prerequisite; no filler. The telegraphic noun-list style is efficient but slightly cryptic ('the house', 'in house') for an agent unfamiliar with the domain vocabulary.

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 read-only, single-parameter, non-destructive report with no output schema, the description covers what is returned and the auth requirement, which is enough to call it correctly. Only ambiguity around 'house' meaning the property and the absence of a contrast with 'availability' keep it from a 5.

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 coverage is 100% and the single 'date' parameter already documents its YYYY-MM-DD pattern and 'default today' behavior. The phrase 'for one day' vaguely implies the date scoping but adds no syntax or interpretation beyond the schema, so the baseline 3 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 names the exact content the tool returns: arrivals, departures, in house, rooms by housekeeping status, and rooms out of order, all scoped to a single day. That is a specific resource snapshot rather than a restatement of the name. It does not, however, distinguish this from siblings such as 'availability' or 'stays', so an agent must infer the boundary.

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?

'For one day' implies the temporal scope and 'Needs the owner's sign-in' states an auth prerequisite. There is no explicit when-to-use guidance and no mention of when to prefer 'availability' or 'stays' instead, leaving the choice to inference from sibling names.

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

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

Annotations already establish that this is a non-read-only, non-destructive, closed-world mutation. Beyond that, the description adds two pieces of genuinely useful context: the operation dispatches an e-mail, and it requires owner credentials. It does not cover idempotency or duplicate-invite behavior, so it falls short of fully describing the side effects.

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?

Two short sentences, with the action stated first and the credential prerequisite second. Nothing is padded, though the extremely terse phrasing trades away some useful detail that could have occupied the same space.

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 3-parameter mutation with no output schema, the definition covers the core action and the auth requirement but leaves open what the caller receives, whether the invite can be resent or revoked, and how an already-invited address is handled. It is adequate to attempt the call but thin for confident 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?

Schema coverage is 67% and only email and full_name are annotated, so the role field arrives with an enum but no explanatory text. The phrase 'front-desk employee or a manager' loosely maps to the employee/manager enum values and hints that role is optional, but neither the optionality nor a default role is stated.

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 a concrete effect ('E-mails a sign-in') and the target resource ('a front-desk employee or a manager'), so an agent can tell this provisions a staff account rather than editing one. It is clear without needing to contrast against any sibling, though none of the listed siblings overlap enough to require explicit differentiation.

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?

Usage is implied through the stated prerequisite ('Needs the owner's sign-in'), which tells the agent this is an owner-level action. There is no explicit when-not guidance, no note about what to do if a staff member already exists, and no alternative tool named for related account changes.

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

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered; the description adds valuable context beyond them by disclosing the owner-level authentication requirement and sketching what the result contains (trigger timing, enabled state). It stops short of noting ordering, scope, or whether disabled automations are included.

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?

Two short sentences with no filler; the resource statement is front-loaded ahead of the auth prerequisite. The telegraphic sentence fragment ('The hotel's automations: ...') is efficient but slightly reads as a label rather than an instruction.

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 zero-param, non-destructive read with no output schema, the description supplies the three things an agent needs: what the tool returns, the auth requirement, and implied scope. Minor gaps remain around result ordering and whether inactive automations appear, plus the unresolved overlap with 'automation_status'.

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 takes zero parameters, so the baseline is 4; there is nothing parameter-related for the description to compensate for, and the schema has no gaps. The description correctly implies a whole-hotel, unfiltered listing consistent with an empty input schema.

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 resource (automations) and previews its contents ('what each sends, when, and whether it is on'), but never states a verb such as 'list'/'retrieve', leaving the read intent to be inferred from the name and readOnlyHint. It also does not differentiate from the sibling 'automation_status', which plausibly also concerns whether an automation is on.

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 only usage-relevant statement is the prerequisite 'Needs the owner's sign-in' — a genuine condition, but there is no when-to-use guidance, no exclusions, and no mention of how this differs from 'automation_status'. An agent must guess which of the two automation tools to call.

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

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

Annotations already establish that this is not read-only, not open-world, and not destructive, but the description adds important behavioral context: it is a two-phase operation requiring a preview and owner approval. It also discloses the owner sign-in requirement. It does not discuss idempotency, what happens to rows not confirmed, or detailed side effects beyond loading into the hotel.

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 three short sentences and front-loads the core action before explaining the two-step workflow and the sign-in requirement. Every sentence adds useful information with no filler.

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 one-parameter mutation tool with no output schema, the description covers the essential workflow, approval step, and authentication prerequisite. It does not fully explain what the preview returns, how decisions are represented, or error behavior, but it is complete enough for an agent to use the tool correctly in normal operation.

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 schema already documents the single confirm parameter, but the description adds substantial meaning: omitting confirm produces a preview of rows needing a decision, while confirm true loads them. This explains the parameter's role in the workflow beyond the schema's brief 'true to load' text.

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 and resource: it loads stays read from reports into the hotel. It also distinguishes the action from a simple read by describing the preview-then-confirm workflow. It does not explicitly name sibling tools such as stays or upload_report, so it stops short of full sibling differentiation.

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 gives clear usage guidance: call first without confirm to preview rows, show them to the owner, then call with confirm true. It also states the prerequisite that the owner must be signed in. It does not describe when not to use this tool or compare it directly with sibling alternatives.

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

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context beyond them: the authentication requirement (owner sign-in) and the fact that the response includes a test-mode flag, which an agent should know before trusting the data.

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?

A single front-loaded sentence identifies the resource, then enumerates the returned fields, then states the auth prerequisite. Every clause carries information; nothing is redundant with the title or annotations.

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?

With no output schema, the field enumeration does the work of describing the return payload, and the auth requirement is disclosed. It stops short of covering edge behavior, such as what happens if the owner has no hotel configured or whether more than one hotel can be returned.

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 takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The schema is fully closed (additionalProperties=false) and consistent with the no-argument description.

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 hotel's details" names a specific resource and the enumeration of fields (name, address, phone, rooms, check-in/check-out, taxes, test mode) makes the retrieval concrete. It does not distinguish itself from siblings like house_inventory or setup_status, but the read-the-hotel-record purpose is unambiguous.

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?

Usage is implied rather than stated: the agent can infer this is the call for the current hotel's profile, and the note that it "needs the owner's sign-in" is a useful prerequisite. However, there is no explicit when-to-use/when-not guidance and no routing to alternative siblings that also surface property information.

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

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

Annotations already state readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: accepted image formats, a 10 MB size ceiling, and the owner-authentication requirement. It stops short of saying whether an existing logo is replaced or what happens on a rejected URL, which is the main remaining gap.

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?

Two sentences with no filler, and the core action is front-loaded before the constraints and the auth precondition. Every clause carries usable information.

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 one-parameter mutation with annotations covering the safety profile and no output schema, the description is nearly complete: it covers the source, formats, size limit, and auth. What it omits is whether setting a logo overwrites the previous one, which matters for an agent judging side effects.

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 single parameter is fully documented in the schema ("Public https address of the logo"), so the baseline is already high. The description still adds value by constraining that URL to PNG/JPEG/WebP and a 10 MB cap, information the schema does not carry.

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 gives a specific verb and resource ("Sets the hotel's logo") plus the source of the asset (a public web address). It does not distinguish itself from the sibling add_photo, so an agent must still infer whether logo-setting is a distinct operation from adding a photo.

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 supplies a real precondition ("Needs the owner's sign-in"), which tells the agent when the call will be permitted. It gives no guidance on when to choose this over add_photo or how it relates to other hotel-profile tools, so the routing guidance is only implied.

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

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

The annotations already declare this as a safe read-only operation, and the description adds useful context: it returns checklist statuses and requires the owner's sign-in. It does not mention rate limits or detailed return structure, but for a read-only status tool the added behavioral context is solid.

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 brief and front-loads the setup-step content before the sign-in prerequisite. The first sentence is compressed into a noun-phrase list rather than a complete verb-led statement, which slightly reduces immediate clarity but keeps the definition efficient.

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 parameterless, read-only checklist-status tool with no output schema, the description gives enough context about what the result contains and the authentication requirement. It could be slightly richer about return shape, but it is complete enough for an agent to understand and invoke the tool.

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 has zero parameters, so there is no parameter meaning for the description to add. The baseline for a parameterless tool is 4.

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 identifies a specific resource: the 12 setup steps and their statuses, including findings, decisions, and reports read. It is clear enough to distinguish this from generic status tools, though it does not explicitly contrast with siblings such as automation_status or tasks_waiting_on_me.

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 only guidance is the prerequisite that it needs the owner's sign-in. There is no explicit when-to-use guidance, no exclusions, and no routing to sibling tools like start_signup or tasks_waiting_on_me.

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

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent, closed-world write, and the description adds real value on top: creation happens in free test mode and the e-mail becomes the sign-in, which is a post-condition the agent must know. It stops short of warning that repeating the call may create a duplicate owner/hotel, which matters given idempotentHint=false, and says nothing about failure modes such as an e-mail already existing.

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, front-loaded sentences: what it does, when to use it, and what changes afterwards. No filler, and the precondition precedes the consequence.

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 four-required-parameter creation tool with no output schema, the description covers the trigger condition and the immediate downstream effect, which is what an agent needs to sequence calls. It omits what the call hands back (e.g., a hotel or owner identifier) and the natural next step, leaving a small gap for an agent that must chain into setup_status or my_hotel.

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 coverage is 100%, so all four parameters are documented in the input schema itself. The only semantic note in the description ('that e-mail' becomes the sign-in) restates the schema's own 'Owner e-mail (becomes the sign-in)' text, adding no new meaning.

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 a specific verb and resource ('Creates the hotel in Guest Logic') and pins the mode ('free test mode'). Combined with the title's qualifier ('no account yet'), an agent can distinguish this provisioning tool from siblings such as my_hotel, setup_status, or invite_staff without opening a schema.

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 states an explicit precondition and an explicit exclusion: 'Use only when the owner has no Guest Logic account.' It also describes the consequence that selects the alternative path — after this call, any other tool triggers the sign-in for that e-mail.

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

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

The annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond them, "Needs the owner's sign-in," which tells the agent an authentication prerequisite exists. It says nothing about what is returned or how a bad confirmation number is handled.

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?

Two short, front-loaded sentences with no filler; the resource and key come first and the access prerequisite second. Nothing could be removed without losing information.

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 one-parameter read tool this is close to sufficient, and the auth note is a real addition. However, with no output schema present, the description never indicates what a returned stay contains, leaving the agent guessing at the response shape before calling.

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 coverage is 100% for the single parameter, so the schema already defines confirmation as a string confirmation number. The phrase "by its confirmation number" only confirms the parameter is the stay's confirmation identifier, adding little beyond the schema.

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?

"One stay by its confirmation number" gives a specific resource (a single stay record) and the exact lookup key, implicitly contrasting with the plural sibling stays. It stops short of explicitly naming stays or load_stays, so the agent must infer the singular/plural split.

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?

Usage is implied rather than stated: use this when you already hold a confirmation number for a single stay. There is no explicit statement of when to prefer stays or load_stays instead, and no stated failure condition such as an unknown confirmation number.

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

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

The annotations already declare this is a read-only, non-destructive, closed-world operation. The description adds meaningful behavioral context beyond annotations: the date-range cap, pagination limit, auth requirement, and the shape of returned stay records.

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 compact and front-loaded: it states the core scope, record fields, pagination, and auth requirement in three short clauses. Every phrase carries useful information with no unnecessary wording.

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 read-only list tool with annotations covering safety and no output schema, the description gives enough context to call it correctly: date range, return fields, pagination, and auth. It is only missing explicit sibling routing guidance and status-filter semantics.

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?

With 50% schema description coverage, the schema documents from and to but leaves page and status without descriptions. The description clarifies that page is for additional rows beyond 200, but it does not explain the status filter behavior or how the listed fields relate to the status parameter.

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 states a specific resource and scope: stays touching a date range, with a 31-day limit and listed record fields. It distinguishes the operation from a generic stay lookup by emphasizing the date range and pagination, but it does not explicitly differentiate from siblings such as stay or load_stays.

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 provides useful usage constraints: maximum 31 days, 200 rows per call, use page for more, and owner sign-in required. However, it does not state when to use this tool instead of related siblings like stay, load_stays, or availability, leaving the agent to infer routing.

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

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.

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds a real behavioral fact beyond that: the call acts on the current signed-in owner's data and requires their authentication. It says nothing about volume, ordering, or what counts as 'open'.

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?

Two short sentences, no filler, with the scope stated first and the auth precondition second. Nothing could be removed without losing information.

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 zero-parameter read tool the critical facts are what it returns and how the caller identifies itself, and the description covers only the latter. With no output schema, an agent still does not know the shape of a task (id, title, due date, board position) or whether results are ordered or bounded.

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 takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The schema confirms an empty object with additionalProperties false, consistent with the description's claim that scope comes from the session, not inputs.

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 gives a specific resource and scope: open tasks on the signed-in person's Home board. That is clearly distinguishable from every sibling tool listed (photos, stays, automations, signup), none of which read tasks, so no explicit sibling routing is needed.

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?

Usage is only implied by 'open tasks' and 'signed-in person's'; there is no statement of when to prefer this over another way of getting task data, and no exclusions. The sign-in precondition is the only guidance-like content, and it is a prerequisite rather than a when-to-use rule.

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

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

Annotations only declare the readOnly/destructive/openWorld triple; the description adds substantially more: a 4 MB limit, accepted formats, an owner-authentication requirement, the side effects (creating rooms, room types, rates, taxes, stays), and a return signal ('Returns what was found'). That is meaningful behavioral disclosure beyond structured fields.

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?

One dense sentence plus two short ones, with the send/scope constraint front-loaded and the side effects and prerequisite trailing. There is no filler or restatement of the name.

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 two-parameter ingest tool with no output schema, the description covers formats, size, auth, and what the server does with the content, which is close to sufficient. It omits edge behavior such as duplicate re-uploads, parse failures, or whether an upload can be undone.

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 coverage is 100%, so the baseline is 3; the description earns one step above by constraining the content parameter to CSV, tab-separated or plain text under 4 MB, which is not stated in the schema. The filename parameter gains nothing beyond the schema's own example ('bookings.csv').

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 and resource ('Sends one report's content as text') and immediately identifies what the tool produces ('sets up what it can (rooms, room types, rates, taxes, stays)'). It is clearly distinguishable from siblings like load_stays or submit_facts, though it never names an alternative explicitly.

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 direction: 'read a PDF or spreadsheet first and send its rows', plus the accepted text formats and size ceiling, and the prerequisite 'Needs the owner's sign-in.' It stops short of stating when not to use this tool or which sibling to prefer for adjacent tasks.

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