Desky

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

Goes beyond the readOnly/idempotent annotations by disclosing that hours are in the venue's local time, never UTC, with the IANA zone in the response, and that no occupancy levels are reported. That is real context an agent would otherwise get wrong.

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, well-ordered sentences with the key constraint (local time, not UTC) emphasized. Minor overlap with the schema's date description but no wasted text.

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?

An output schema exists, yet the description helpfully explains the timezone field and the limits of the result. The only gap is not stating that a space identifier (slug or space_id) must be provided.

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 adds nothing about parameters beyond what the schema already documents (notably it never clarifies that one of slug/space_id must be supplied despite zero required params).

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 (returns free dates/hours of a space) and adds scope detail (hours only when sold by the hour). Clearly distinct from search_coworks and quote_booking, though siblings are never named.

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 about final confirmation at checkout implies this is pre-booking information-gathering, but no explicit when-to-use guidance or alternative (e.g. quote_booking, get_booking_link) is named.

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, idempotentHint, non-destructive and openWorld, so the safety profile is covered. The description contributes beyond that by disclosing a side effect the annotations cannot convey: optional date/spots input produces a prefilled booking link, which matters for callers deciding whether to supply those 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?

Two sentences, front-loaded with the resource and its scope, then the identifier/parameter guidance. The long field enumeration is somewhat redundant given an output schema exists, but it does communicate breadth of the response in one glance, so the length is defensible.

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?

Covers identifiers, optional prefill behavior, and the shape of the response, and an output schema exists so return values need no further explanation. The remaining gap is workflow placement: it does not tell the agent whether to call this before check_availability/quote_booking/get_booking_link or in place of them.

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 every parameter is already documented inline, and the description mostly echoes the schema ('to prefill the booking link' is verbatim from the `date` and `spots` descriptions). It correctly flags space_id vs slug as alternatives, but says nothing about currency, utm_source, or the starts_at/ends_at pairing, so it adds 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?

States a concrete verb/resource ('Full listing of a space') and enumerates exactly which fields come back: description, venue, address, capacity, pricing tiers, amenities, hours, rating and reviews. It ties itself to search_coworks as the producer of its identifiers, which helps an agent slot it into the workflow, but it never explicitly contrasts with check_availability, quote_booking or get_booking_link.

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 clear entry path ('space_id` or `slug` (`search_coworks` returns both)') and states the value-add of passing date/spots: the booking link comes prefilled. That is real usage context, but there is no when-not guidance and no statement of how this differs from the availability/quote/link siblings.

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 readOnly, idempotent, non-destructive, open-world behavior. The description adds genuinely useful context beyond that: it does not book or charge, the person confirms on the site, and sharing the link is sufficient. It does not cover auth, rate limits, or failure modes, but the key side-effect expectation is clear.

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 what the tool returns and immediately followed by the key no-booking caveat. 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?

With 8 optional parameters, a 100% schema coverage, an output schema, and rich annotations, the description supplies the essential missing behavioral context: no booking, no charge, final action, share the link. It does not explain space identifier selection or multi-date behavior, but those are covered by the 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 the schema already documents all 8 parameters, including date, dates, spots, slug, space_id, and times. The description adds only that the date and number of people are embedded in the returned link, without explaining the identifier alternatives or time parameters beyond what the schema provides.

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 returns the desky.la booking link for a space with date and party size prefilled. It does not explicitly name or differentiate itself from siblings like check_availability or quote_booking, so it misses the top-band sibling-differentiation criterion.

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 useful implied usage context by saying this is 'the final action of this server' and that 'sharing the link is enough.' However, it never states when to use this versus check_availability or quote_booking, nor does it mention prerequisites such as resolving a space first.

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 that this is read-only, idempotent, non-destructive, and open-world. The description adds useful behavioral context beyond that: the returned total is final rather than an estimate, the checkout link is returned, and no booking or charge occurs.

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 front-loaded with the core action and return values, then adds useful context about final pricing and non-booking behavior. It is efficient, though the Desky-interface sentence is contextual rather than essential.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given rich annotations, a complete input schema, and an output schema, the description provides enough context for correct selection and invocation. It covers purpose, usage context, return meaning, and non-side-effect behavior without duplicating structured fields.

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 parameter semantics are already well documented in the schema. The description only indirectly references date and seat count and adds no syntax, precedence, or format details beyond what the schema provides.

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: it quotes a booking and returns the final total plus the checkout link. It also distinguishes the operation from booking/charging, but it does not explicitly differentiate itself from siblings like check_availability or get_booking_link.

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 a clear usage context: the Desky interface uses it when the person changes the date or number of seats. It also clarifies that it does not book or charge, which helps avoid misuse, though it does not name alternative tools or exclusion cases.

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 readOnly/idempotent/non-destructive, and the description builds well past them: it discloses the non-obvious semantics that prices are list prices per unit, never a total, and that the final price is computed at checkout, plus how `price_from_period` maps to desks/offices/rooms. It also warns that the date parameter does not function as an availability filter.

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-loaded with purpose, then a sharp exclusion, then the two highest-value parameter hints. The closing instruction about not presenting list prices as totals is worth keeping but is slightly chatty with an extra clause telling the assistant not to mention it every time.

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 10-parameter, zero-required search tool with an output schema and full annotation coverage, the description covers scope, return shape, pricing semantics, the availability boundary, and the key parameter behavior. Nothing an agent needs to call it correctly 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?

Schema coverage is 100%, so the baseline is 3; the description adds genuinely new meaning by explaining that `capacity` both filters results and prefills the booking link with that seat count, and by clarifying the unit basis of prices. Both facts go beyond what the schema text conveys.

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 (searches workspaces published on Desky) and enumerates the filter dimensions (city, neighborhood, type, capacity, price) plus the exact return payload. It also names the sibling it is not (check_availability), so the agent can route without opening either 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?

Explicitly states the tool does not filter by availability and directs the agent to `check_availability` for that. It additionally instructs passing `capacity` when the person stated a headcount. It does not differentiate from `cowork_detail` or `get_booking_link`, which is the only gap.

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