hostfully

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

readOnlyHint=true is already declared, but the description adds real value by flagging that this is a non-mutating quote despite being a POST endpoint (Hostfully: POST /api/v3.3/quotes) and that nothing is persisted. It does not cover auth requirements, rate limits, or error behavior, so it falls short of a 5.

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 outcome, then the non-mutation guarantee, then the upstream endpoint. 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?

There is no output schema, and the description partially compensates by naming the quote components returned. Still, it does not state whether the quote is time-limited, what happens on unavailable dates, or how the total is structured, leaving some return-shape ambiguity for a tool with no output schema.

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 100%, so all 8 parameters (including lead_uid, pet_count, children_count, agency_uid) are already documented in the schema. The phrase 'for the given dates and party' adds no syntax or constraint detail beyond what the schema provides; 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?

Specific verb ('price') plus resource ('a prospective stay at one property'), with an enumeration of what is computed (rent, fees, taxes, security deposit, total). The clause 'Computes only — creates nothing' cleanly separates it from the create_job/create_lead 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 is implied by 'prospective stay' — call it to price a stay before booking. But there is no explicit when-to-use statement, no prerequisites, and no routing to alternatives such as hostfully_get_pricing_periods when the agent wants base rates rather than a full quote.

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 carry destructiveHint=true, so the description does most of the behavioral work. It usefully discloses that times are property-local (a real behavioral constraint not in the schema), but it says nothing about permissions, what the created job returns, or how scheduling conflicts or idempotency are handled. Adequate but thin for a create tool.

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, each earning its place: purpose, time semantics, prerequisite tool, and endpoint. The core action is front-loaded and there is 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?

With no output schema, the description would ideally note what the call returns, and annotations are minimal. However, it covers the key operational facts an agent needs — property-local timing, the UID source, optional lead linkage, and the endpoint — making it largely complete for a create call.

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 already 86%, so most params are documented there. The description still adds value by explaining that 'Times are property-local' — critical semantics for timezone-less START/END patterns — and by clarifying that lead_uid is optional. It does not elaborate on the status enum beyond what the schema states.

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 ('Schedule a job'), scopes it with concrete examples ('a cleaning or a guest greeting'), and locates it as a service-at-property operation optionally tied to a lead. This distinguishes it clearly from siblings like hostfully_create_lead or hostfully_list_jobs without needing to open any 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?

Provides real routing guidance: it names 'hostfully_list_services' as the source of the service UID and clarifies that the lead tie-in is optional. There is no explicit when-not or description of failure conditions, but the prerequisite pointer gives clear operational context.

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?

Adds real context beyond the destructiveHint annotation: that a BLOCKED entry can be removed later in Hostfully, that inquiries flow through the normal pipeline without confirming a booking, and that dates are property-local. It does not disclose auth/rate-limit behavior, but for a create tool the side-effect disclosure is substantive.

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 tight sentences, front-loaded with the core action and mode distinction, then side effects, then the endpoint. No filler; every clause carries 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 nested 8-parameter create tool with no output schema, the description covers both modes and their consequences adequately; the schema handles parameter detail. It could note whether the created lead is returned or how to retrieve it, but overall it is complete enough to invoke correctly.

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 100% and the schema already documents status semantics and property-local dates, so the description largely repeats structured data. It adds no syntax or constraint detail the schema lacks, making 3 (baseline) 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 (create) and resource (lead) at one property, and immediately distinguishes the two modes via status BLOCKED vs NEW. An agent can tell this apart from siblings like update_lead or search_leads from the text alone.

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?

Clearly explains the two use cases (owner/maintenance block vs guest inquiry) and clarifies that an inquiry does not confirm a booking or take payment. It lacks an explicit pointer to alternatives (e.g., update_lead for later edits), so it stops short of full when/when-not/alternatives guidance.

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?

readOnlyHint=true already establishes this as a safe read, and the description adds real value on top: it enumerates the lead sub-types that share this endpoint and previews the returned surface (status, channel, dates, guest info, notes, assignee), which matters because no output schema exists. It omits error behavior for unknown UIDs and any rate-limit or auth context.

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 primary clause is front-loaded and does the real work; the trailing endpoint reference is terse and useful for debugging. Nothing is padded, though the second sentence is reference material rather than agent-facing guidance.

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 with safety covered by annotations, the description is nearly sufficient: it names the sub-types and summarizes the return fields in lieu of an output schema. The only notable gap is not telling the agent where to obtain a valid lead_uid.

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 100% and the single parameter's description ('The lead's UID') is as thin as the schema's. The description adds no format, source, or lookup guidance for the UID beyond what the schema already says, 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?

States a specific verb and resource ('Fetch one lead ... by UID') and enumerates what a lead can be (booking, inquiry, booking request, block), which sharpens the concept considerably. The plural/singular distinction versus hostfully_search_leads is implied by 'one ... by UID' but never made explicit.

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: fetching a single entity when you have its UID. There is no explicit guidance on when to reach for this instead of hostfully_search_leads, nor any note on where a valid lead_uid comes from (e.g., search results or other list endpoints).

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?

readOnlyHint=true already establishes this is a safe read, so the description doesn't need to restate that. It adds useful context about what each returned entry contains, but says nothing about pagination, result limits, or behavior for properties without pricing periods configured.

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, front-loaded with the substantive content. The trailing 'Hostfully: GET /api/v3.3/pricing-periods' is mildly redundant but compact and does hint at the upstream contract.

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 description carries the burden of describing returns; it names the fields but doesn't explain the shape (per-date entries, ordering, gaps for unpriced dates). Adequate for a simple three-param read, but leaves the agent guessing about result structure.

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 100% (property_uid, from, to all documented with types and YYYY-MM-DD patterns), so the baseline is 3. The description's phrase 'one property over a range' loosely maps to the params but adds no format or constraint detail 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?

The description states the specific resource and scope: nightly price, minimum stay, and check-in/check-out availability for each date of one property over a range. It clearly conveys what data is retrieved, though it doesn't explicitly differentiate itself from siblings like hostfully_get_property_calendar or hostfully_calculate_quote.

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?

No guidance on when to choose this over hostfully_get_property_calendar or hostfully_calculate_quote, and no stated prerequisites or conditions. The agent must infer usage from the name alone.

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 readOnlyHint annotation already tells the agent this is a safe, non-mutating read, so the description only needs to add context beyond that. It usefully scopes what the response contains (pricing, availability, channel data, cancellation policy), but says nothing about auth requirements, rate limits, or failure behavior for a missing UID.

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 front-loaded sentence listing the returned fields, followed by the underlying API route. No filler, and the essential information comes first.

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 and only one input parameter, the description's enumeration of returned detail categories (address, time zone, rooms, pricing, availability, channel data, notes, cancellation policy) does meaningful work in place of a return schema. It is close to complete, missing only error/edge-case behavior.

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?

There is a single required parameter with 100% schema description coverage, so the schema already documents property_uid fully. The description adds no format, syntax, or sourcing guidance beyond it, which matches the baseline for high schema coverage.

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 (fetch) and resource (one property) and enumerates the returned detail categories, which clearly separates it from the plural sibling hostfully_list_properties.

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?

'Fetch one property's full details' implies the use case (retrieve a single property by UID), but the description never names an alternative or states when to prefer this over hostfully_list_properties or hostfully_get_property_calendar. Usage is implied rather than explicit.

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, so the safe-read profile is covered and the description is not obligated to restate it. The description adds useful framing about response granularity (day-by-day) and the underlying API path, but says nothing about pagination, date-range limits, or whether pricing is quoted per night vs total. Adequate, not rich.

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 tight clauses front-load the payload and the framing question before the API reference. Nothing is redundant, though the endpoint citation is marginally useful at best for an agent that already has the tool binding.

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 description carries some burden for return shape and does hint at it ('day-by-day availability and pricing'). Required params are all in the schema. It stops short of describing response structure or error behavior, but for a read-only calendar lookup it is close to sufficient.

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 100%, so from/to/property_uid/availability_comments are all documented in the schema itself (including the YYYY-MM-DD pattern). The description adds no parameter-level detail beyond the schema, which is the expected baseline when the schema does the heavy lifting.

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 concrete verb-and-resource pair: day-by-day availability and pricing for one property over a date range. The framing question ('is it free, and at what price?') pins down the exact data returned, and the endpoint reference (GET /api/v3.3/property-calendar/{propertyUid}) confirms scope. An agent can distinguish this from list-style siblings immediately.

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 phrase 'the direct answer to is it free, and at what price?' implies the use case well, but no alternatives are named. Siblings such as hostfully_calculate_quote and hostfully_get_pricing_periods overlap this territory, and the description never says when to prefer one over the other. Usage is inferred rather than stated.

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 readOnlyHint annotation already declares this is a safe read operation. The description adds useful behavioral context beyond that: it is scoped to agencies accessible by the API key and returns UIDs, currency, and default check-in/out times. It does not cover pagination or rate limits, so it falls short of the highest transparency tier.

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 only three short sentences, front-loads the purpose, then the usage cue, then the endpoint. Every sentence earns its place with no redundant or vague phrasing.

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 list tool with no output schema, the description provides enough context: it states access scope, returned fields, and when to call it. There is no output schema to require explanation, and no missing behavioral detail that would prevent correct invocation.

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 the description has no parameter semantics to explain. Per the baseline for zero-parameter tools, this dimension is naturally well-covered without additional 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 ('List the agencies'), names the scope ('this API key can access'), and enumerates returned fields including UIDs and check-in/out times. It is easily distinguishable from sibling list tools, which cover guests, jobs, messages, orders, owners, properties, reviews, services, and threads.

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 clear usage context: 'Start here to find the agency_uid other tools need.' This tells the agent when to call it relative to other tools. It does not include explicit when-not conditions or name alternatives, but no sibling tool lists agencies, so the guidance is strong without being exhaustive.

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, so the safe-read profile is covered. The description adds useful context by listing the returned field categories and citing the underlying GET endpoint, but says nothing about pagination, result limits, or auth, so it stays at an adequate level.

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 tightly packed clauses with the resource and returned fields front-loaded. Efficient overall, though the appended API endpoint reference is slightly redundant for an agent consumer.

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?

A read-only list tool with one optional parameter, no output schema, and safety already covered by annotations. The description compensates for the absent output schema by naming the returned fields, leaving only pagination/ordering unaddressed.

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 parameter's default (HOSTFULLY_AGENCY_UID) and lookup path (hostfully_list_agencies) are already documented in the schema. The description adds no param-level meaning beyond that, 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?

States a specific verb ("List") and resource (the agency's guest records), and enumerates the returned fields (names, email, phone, address, profile notes), making it distinguishable from list_agencies, list_properties, and other siblings at a glance.

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 offers no when-to-use, when-not-to-use, or alternative guidance. It doesn't tell the agent when to prefer this over search-style siblings, nor what prerequisites exist (beyond the UID default noted in the schema).

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, so safety is covered. The description adds genuinely new behavior: results are sorted by start date, and it names the backing endpoint (GET /api/v3.3/jobs). It still omits pagination/volume limits for a window-scoped list, 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?

A single front-loaded sentence covering scope, optional filters, and ordering, followed by a compact endpoint reference. No filler, no repetition of the title.

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, filter-based list tool with a fully documented schema and no output schema, the description supplies scope, filters, and ordering. It does not indicate what a job record contains or whether results are paginated, which would matter for an agent processing large date windows.

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 100% — every parameter (from, to, statuses, property_uids, modified_since) is already documented in the schema, including the required and default behavior of modified_since. The description only restates the date-window/filter semantics at a high level and adds no format or usage detail beyond the schema, so 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?

States a specific verb (List) and resource (operational jobs) and even disambiguates what a 'job' is with the parenthetical (cleanings, greetings, maintenance, other services), which separates it from hostfully_list_services. It does not explicitly name a sibling to contrast with, so it lands just short of a 5.

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 implies usage by noting the date window is the primary scope and properties/statuses are optional narrowing filters, and it states the sort order. It gives no explicit when-to-use/when-not-to-use guidance nor points to create_job or list_services as 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 only declare readOnlyHint=true, so the description carries the rest: it discloses cursor pagination, the returned field set (sender type, status, content), and the underlying endpoint. It does not explicitly state that results are read-only/ordered, but it adds solid behavioral context beyond the annotation.

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 tight sentences, front-loaded with the resource and channel scope, followed by selector guidance and pagination. No filler; only the trailing endpoint reference is arguably redundant.

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 description compensates by naming the returned fields and pagination behavior, and it covers all selector paths. Nothing critical is missing for a read-only list tool, though result ordering and empty-result behavior go unstated.

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 100%, so the schema already documents limit, cursor, lead_uid, agency_uid, created_at and thread_uid. The description restates the selector parameters and cursor pagination but adds no format or semantics beyond what the schema provides, matching the baseline 3.

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 (read) and resource (guest messages) plus the channel scope and the three selectable scopes (lead/thread/agency). It is clear what the tool returns (sender type, status, content). It stops short of explicitly distinguishing itself from siblings like hostfully_list_threads or hostfully_get_lead.

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 tells the agent which identifier to supply ('Give lead_uid, thread_uid, or agency_uid (or the default)'), which is implied usage guidance, but it never says when to prefer this over hostfully_list_threads or when to reach for hostfully_get_lead. No exclusions or prerequisites are given.

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, so the safety profile is covered. The description adds the underlying endpoint (GET /api/v3.3/orders) and the domain meaning of the returned payload, but says nothing about pagination, result limits, or ordering of results, which matter for a list endpoint.

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?

Front-loads the resource definition, then the filtering rule, then the endpoint reference. No filler, though the raw endpoint citation earns slightly less than the semantic content around it.

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 no output schema, the description supplies the domain meaning of an 'order' and the mandatory filter rule, which is enough to invoke it correctly. Missing pagination/shape hints keeps it from being fully complete.

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 100% and each parameter is documented in the schema (lead_uid, guest_uid, property_uid, updated_since with format example). The description corroborates the filter set but adds no syntax or format detail beyond the schema, so 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?

States a specific verb+resource (list orders) and goes further by defining what an order actually is — 'the money side of a booking: rent, fees, services, adjustments, taxes, channel commission and total'. That framing lets an agent distinguish it from the other hostfully_list_* tools on semantic grounds rather than name alone.

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?

Gives explicit filter context and a hard usage constraint — 'at least one is required' among lead/property/guest/update time — which is essential to call it correctly. It stops short of naming alternatives (e.g. when to use search_leads or get_lead instead), so no when-not guidance.

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 readOnlyHint=true, so the safety profile is already known. The description adds value by disclosing the returned field set (contact details, commission rate, permissions) and the optional filtering behavior — meaningful context beyond the annotation. However it says nothing about pagination, result limits, or whether agency_uid scoping constrains results.

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 covers purpose, returned fields and the optional filter; the trailing endpoint reference is compact and useful. Slightly dense but no wasted sentences.

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 a 100%-covered 2-param schema and no output schema, the description is nearly sufficient — it names the returned fields, which the absent output schema would otherwise leave unknown. Missing only pagination/limit behavior and explicit sibling routing to be fully complete.

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 both parameters are fully documented in the schema, including the agency_uid default and the cross-reference to list_agencies. The description restates the optional search filter but adds no syntax or format detail beyond the schema, so the baseline of 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?

States a specific verb (List) and resource (the agency's property owners) and enumerates the returned fields — contact details, business name, commission rate, permissions — which distinguishes it from list_guests, list_properties and other list siblings. The name, title and description all align without redundancy.

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 mentions the optional search-string filter, implying when to use it, but gives no explicit when-to-use vs alternatives or exclusions. With 19 sibling list/get tools, an agent gets no routing guidance (e.g. use this rather than search-style tools).

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 readOnlyHint=true, so the description earns credit for adding the return shape (name, address, type, bedrooms, active flag, pricing/availability settings), which matters because there is no output schema, plus the cursor-pagination model and the underlying API route. It still omits auth/permission needs and default page size.

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 resource and returned fields, then pagination and the API mapping. The endpoint citation is mildly redundant but cheap and locates the tool in Hostfully's API surface.

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 description usefully compensates by enumerating returned fields and flagging cursor pagination, and the schema covers defaults for agency_uid. Missing details such as default page size and behavior when updated_since is combined with cursor are minor.

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 100%, so the schema already documents limit, cursor, agency_uid and updated_since with formats and defaults. The description adds no parameter-level syntax or constraints beyond what the schema provides, making the baseline 3 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 ('List an agency's properties (rentals)') and enumerates the returned fields, and the plural vs. the singular hostfully_get_property sibling is self-evident. It never names a sibling explicitly, so it falls short of the top band, but an agent can tell what it does at a glance.

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 when-to-use or when-not guidance and no mention of alternatives such as hostfully_get_property for a single property. The agent must infer that this is the bulk-listing counterpart to the get-one tool. Only the endpoint reference hints at context.

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, so the safety profile is covered. The description usefully adds that results are cursor-paginated and that the payload includes private feedback and host responses, which is real behavioral context beyond the annotations. It stops short of noting filter combinations or ordering defaults.

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. The returned-field list and the pagination trait are front-loaded immediately after the verb+resource, and the API endpoint citation is appended compactly.

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, non-paginated-output list tool with annotations covering safety and no output schema, the description is sufficient: it names the scope, the pagination model and the returned fields. Minor gaps remain around default sort behavior and the relationship between the two scoping parameters.

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 63%: limit, cursor, lead_uid, property_uid and updated_since are documented in-schema, while sort, source and sort_direction enums are not. The description adds only the property/lead scoping and pagination hints, which map loosely onto parameters rather than explaining them, so it nets out to the schema 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?

States a specific verb and resource ('List guest reviews') and scopes it to a property or lead, plus enumerates the returned fields (rating, title, content, source, private feedback, host response). No sibling tool covers reviews, so no explicit differentiation is needed, but the definition never states how it relates to the get/list family around it.

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 closing line ('for a property or a lead') implies you must supply property_uid or lead_uid, and 'Cursor-paginated' implies iterating. There is no explicit when-to-use guidance, no statement that both scoping params are optional, and no exclusions relative to sibling list tools.

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?

readOnlyHint=true already marks this as a safe read. The description usefully previews the returned fields (provider, price, duration) and the endpoint, but adds nothing about pagination, result size, or auth beyond the schema's default-UID note.

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 compact sentences plus an endpoint reference; the resource description and the create_job dependency are front-loaded 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 read-only list tool with fully documented params and no output schema, the description covers what is listed, example categories, and the downstream use, leaving only minor gaps like result ordering or pagination.

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 100%, so agency_uid, catered_to, and service_provider_uid are already documented in the schema. The description mentions providers and services but adds no syntax or format detail beyond structured fields, so 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?

States a specific verb+resource ('List the services an agency offers or schedules'), gives concrete examples, and names what the resource enables downstream (create_job). An agent can distinguish it from siblings like hostfully_list_jobs or hostfully_list_properties.

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 ties the result to hostfully_create_job ('A service UID is what hostfully_create_job needs'), which implies when the tool is needed, but it never states explicit when-to-use vs. sibling alternatives or exclusions.

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 cover the safety profile (readOnlyHint=true), and the description adds real behavioral context beyond them: it is cursor-paginated and returns participants and read status. It stops short of noting auth or rate-limit behavior, so not a 5.

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 purpose then parameter selection then pagination and endpoint. Efficient, with only minor abbreviation (

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 listing tool with no output schema, the description covers what is returned (participants, read status), how scoping works, and pagination. Adequate for correct invocation; only the sibling disambiguation is missing.

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 75% schema coverage the baseline is 3, but the description adds value: it clarifies the lead_uid/agency_uid alternative and notes the agency default, which shapes how the otherwise-undocumented lead_uid is used. Cursor behavior is also reinforced.

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 (list guest-messaging threads) plus scope (agency or one lead) and the return content (participants and read status). It does not explicitly differentiate itself from the sibling hostfully_list_messages, which is the main gap.

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?

"Give lead_uid, or agency_uid (or the default)" gives clear guidance on which parameters select which scope, but there is no guidance on when to use this thread-listing tool versus hostfully_list_messages or hostfully_search_leads. Usage is only implied relative to tool selection.

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 readOnlyHint=true; the description adds that results are cursor-paginated, enumerates returned fields (status, type, channel, dates, guest info), and cites the backing endpoint. It stops short of stating rate limits, empty-result behavior, or the max result horizon, but the added context is substantive.

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 compact sentences, front-loaded with what a lead is before the filters and return fields. The endpoint citation is the only near-redundant element, and nothing is padded.

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 description compensates by naming the returned fields and pagination mechanism, and no parameters are required so the zero-required constraint is addressed. Missing only edge-case behavior (empty pages, date-range defaults), which is minor for a search 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?

Schema description coverage is 100%, so the schema already documents all 10 parameters including limit, cursor, and the date-range pattern. The description only restates the filter axes and adds the 'or the default' note for agency_uid, which is marginal lift over the schema's own 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?

States a specific verb (Search) and resource (leads), and explicitly decodes Hostfully's non-obvious terminology (leads = bookings, inquiries, booking requests, calendar blocks). The filter axes and the underlying endpoint make it unmistakable versus get_lead or create_lead.

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?

Gives a real invocation constraint ('Give at least one of agency_uid (or the default), property_uid, or lead_uids'), which is useful. But it never says when to choose this over hostfully_get_lead for a known UID or hostfully_list_guests/orders for adjacent data, so sibling routing is left to inference.

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 supply destructiveHint=true; the description adds the crucial real-world consequence — the message "reaches a real guest and cannot be unsent" — which is exactly the behavioral context an agent needs before an irreversible send. It omits auth/permission requirements and rate limits, so it is strong but not exhaustive.

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 tight sentences: purpose and channel scope first, then the irreversibility warning, then the API endpoint. Every clause carries information and nothing is padded.

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 description is responsible for the operation's shape, and it covers purpose, delivery modes, audience restriction, and irreversibility. It lacks any note on what a successful call returns or how errors surface, a minor gap for a 5-parameter 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?

Schema coverage is 100%, so the baseline is 3. The description goes slightly beyond the schema by tying the type enum values to the delivery mechanism and by explaining that DIRECT_MESSAGE is only available for channel leads, which is semantic meaning 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 states a specific verb and resource ("Send a message to the guest of a lead") and scopes it to two delivery modes, distinguishing it from read-side siblings like hostfully_list_messages and hostfully_list_threads. The channel constraint (Airbnb, VRBO, Booking.com leads only) further narrows the purpose beyond what the name conveys.

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 clear when-to-use context: EMAIL vs DIRECT_MESSAGE, and the restriction that DIRECT_MESSAGE only works for channel leads. It also warns to confirm the text before sending. It does not explicitly name a sibling alternative (e.g., list_messages for reading threads), so it stops short of full when/when-not 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 only carry destructiveHint=true, so the description does real work: it discloses merge/partial-update semantics, the Hostfully permission caveat that personal-data fields may be silently ignored, and the underlying PATCH endpoint. It stops short of stating whether omitted fields are preserved on nested guest objects or what the response contains.

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 tight sentences with zero filler; scope, exclusions, and the permission caveat are front-loaded before the endpoint reference. Every sentence earns its place.

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 destructive PATCH with no output schema and partly documented nested params, it covers what is mutated, what is excluded, and an auth-related silent-failure caveat. Missing only merge-merge/null-clearing behavior and any hint at the return payload.

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% on a nested guest object, and the schema itself already documents date formats and 'omitted fields are kept'. The description adds category-level meaning (name, contact, address, arrival/departure) but no syntax beyond the schema, so 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+resource+scope ('Partially update a lead's notes, extra notes and guest details') and immediately bounds it with what it does NOT change (dates, party size, property, status). This lets an agent distinguish it from hostfully_create_lead, hostfully_get_lead, and hostfully_search_leads without opening any 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 'partially update' framing plus the negative scope list makes clear when this tool applies versus full lead creation. However, no sibling is named as the alternative when the excluded fields (dates, party size, status) do need to change, leaving that routing to inference.

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