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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false, non-idempotent, openWorld). The description adds genuine context beyond that: a policy check must happen first and human confirmation is required before invoking. It stops short of describing failure behavior (e.g. what happens when the slot is taken or policy is violated).

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?

Format constraints are front-loaded in the first line, followed by the name/default note and the policy/confirmation rule. Every sentence has a purpose, though the fragmented line layout is slightly choppier than a single tight paragraph.

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 non-idempotent, open-world mutation with no output schema and seven params, the description covers formats and preconditions but omits what a successful call returns (booking id?), how conflicts are handled, and what space_id/building_id mean. Adequate but with clear gaps.

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 0%, so the description carries the burden, and it documents date, start, end formats and the name default. However space_id, building_id, and description — three of seven parameters — get no explanation anywhere, so it only partly compensates for the coverage gap.

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 ('Book a space') and supplies the date/time format up front, so an agent immediately knows what it does. It doesn't name siblings, but cancel_booking/list_my_bookings are obviously different operations, so differentiation is implicit rather than stated.

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 clear preconditions: check the space's booking policy (duration, how far ahead) and confirm with the user before calling. This is actionable when-to-use guidance, though it never names an alternative tool or a when-not-to-use case.

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 destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds a real behavioral requirement not in the annotations: user confirmation before execution. It does not say whether a cancellation can be undone or what happens to the slot afterwards.

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 action and the parameter provenance, with no wasted wording. The confirmation instruction is tacked on but still 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, open-world mutation with no output schema, the definition covers the action and confirmation but leaves out the second parameter, post-cancellation outcome, and failure modes. Adequate to call correctly on the happy path, thin on consequences.

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 0%, so the description is the only source of parameter meaning. It usefully explains where booking_id comes from, but building_id is left completely unexplained, so compensation for the coverage gap is only partial.

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 ('Cancel one of the user's bookings') and scopes it to the calling user, which cleanly separates it from book_space and list_my_bookings. An agent can identify the operation 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?

Gives the precondition (get booking_id from list_my_bookings) and a mandatory pre-step ('Confirm with the user first'), so the calling sequence is clear. It stops short of stating when not to cancel or naming alternatives beyond the listing tool.

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 and openWorldHint=true, so the safety profile is covered. The description adds real value beyond them by unpacking what 'works' means ('signed in, token accepted by the API'), which tells the agent what failure conditions this surfaces. It does not describe the shape of a failed result, keeping it from 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?

One short sentence with the key qualifier (what 'works' means) placed immediately after the claim. No filler, no repetition of the tool 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?

With no parameters, no output schema and annotations covering read-only/open-world behavior, the definition is nearly complete for its complexity. The remaining gap is that it doesn't say what an agent receives on success versus failure (boolean, error, message), which matters for a pure diagnostic 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly does not invent parameter discussion.

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 ('check') and resource ('Roamer X connection') and parenthetically defines what a working connection means (signed in, token accepted by the API). That definition makes clear it is a diagnostic/health-check tool, implicitly distinct from the booking-oriented siblings. It stops short of naming a sibling, so 4 rather than 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?

Use is only implied: an agent can infer this is a connectivity/auth pre-check, but the description never says when to call it (e.g. before other calls, on suspected auth failure) or what to do instead. No exclusions or alternatives 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 and openWorldHint=true, so safety is covered. The description adds that the return includes booking rules, not just static attributes, which is genuinely useful context. It says nothing about behavior on unknown ids, the effect of building_id scoping, or data richness.

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 with the resource, the scope constraint, and the id format example. No filler, and the example is placed where it is immediately usable.

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 zero schema description coverage, the description carries most of the burden. Naming 'details and booking rules' gives the agent a sense of the payload, but the undocumented building_id and the absence of any error/not-found behavior leave real gaps for a two-parameter lookup 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 0%, so the description must compensate. It does well for space_id by giving the expected format and a concrete example ('LIC.4.17'), which the schema lacks entirely. The second parameter, building_id, is not mentioned at all, leaving its purpose (disambiguation? routing?) unexplained.

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: retrieving details and booking rules for a single space, keyed by space id. The singular lookup is implicitly distinguished from list-style siblings like search_spaces and list_locations, but no sibling is named 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?

The phrase 'one space (by its space id)' implies this is the by-id detail lookup rather than a search, so the agent can infer usage. However, there is no explicit when-to-use vs search_spaces, and no mention of prerequisites (e.g., whether the id must come from search_spaces 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds valuable detail about the returned entities: buildings, floors, ids, names, time zone, and space types. It does not cover scoping or pagination, but for a no-parameter list tool this is reasonably transparent.

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 a single efficient sentence with no wasted words. The key return contents are front-loaded and easy to parse.

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 read-only list tool with no parameters and no output schema, the description gives enough information about what is returned. It could more fully specify the shape of space types or the relationship to search_spaces, but it is largely 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?

The tool has zero parameters, so parameter semantics are not applicable. The baseline score 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 provides a clear verb and resource: it lists buildings, floors, and searchable space types. It does not explicitly distinguish itself from sibling tools like search_spaces or get_space, so it falls 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 phrase 'space types you can search for' implies this is useful before searching, but it does not explicitly state when to use this tool versus search_spaces or get_space. Usage is only indirectly signaled.

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 and openWorldHint=true, so safety is covered. The description adds useful default behavior (from_date defaults to today) and the idea of a forward-looking window, but says nothing about result volume, ordering, or how building_id affects 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?

One sentence, no filler, with the format and default for the key parameter front-loaded. Slightly awkward phrasing ('from from_date ... over `days` days') costs a point but nothing is wasted.

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 read-only listing tool with no output schema, the core invocation semantics are present. The omission of building_id's filter effect is the main gap an agent would hit in practice.

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 0%, so the description must carry parameter meaning — it does explain from_date's YYYY-MM-DD format and today default, and gestures at `days`. However, the third parameter building_id is never mentioned and 'over `days` days' is ambiguous about whether it is a window length or a count.

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 the user's bookings') and scopes it to the caller's own bookings, which separates it from search_spaces/list_locations. It does not mention cancel_booking or book_space, but the read-only listing intent 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?

No guidance on when to use this versus siblings such as search_spaces, or when to prefer a wider date window. The only implicit cue is 'the user's bookings', which signals personal scope but gives no exclusions or 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 flag readOnly and openWorld, so the description is free to add the useful parts: results include booking rules and space ids meant for book_space. It doesn't mention result caps (limit default 40) or what happens when nothing is free, which would have completed the picture.

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 core purpose, then formats and enum hints in a compact block. Slightly telegraphic and the trailing newline is wasted, but 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?

No output schema and eight parameters, four of which the description explains. Missing guidance on limit, building_id, and min_capacity, plus no indication of result shape or empty-result behavior, leaves real gaps for a multi-parameter 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 coverage is 0%, so the description must carry parameter meaning. It does well for date/start/end formats, space_type values, and floor formats, but says nothing about limit, building_id, or min_capacity, leaving three of eight parameters undocumented anywhere.

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 with a scope qualifier ('free for the whole slot') that separates it from get_space and list_locations. The closing line tying output to book_space makes the tool's role in the workflow unmistakable.

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?

Points to list_locations for the space_type list and says results feed book_space, which routes the agent through the booking workflow. It stops short of explicit 'use X instead when...' exclusions against get_space or list_my_bookings, but the practical context is clear.

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