Spacery

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

With no annotations, the description carries the full burden and does well: it discloses the free-preview branch for non-paying accounts, the plan default to pay-as-you-go, that a Stripe Checkout link is returned, and the security rule 'Never ask for card details.' It omits error/idempotency/permission behavior, but the disclosure of billing side effects is unusually 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?

Purpose is front-loaded in the first clause, followed by the billing behavior and the follow-up call. Four clauses carry real information, though the payment explanation is dense and could be tightened.

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 2-param, no-annotation, no-output-schema mutation tool, the description covers purpose, the free-vs-paid branch, the returned checkout link, and the required next step. It lacks guidance on failure modes or repeat calls, minor gaps given the otherwise thorough coverage.

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, but the description adds meaning beyond the schema by explaining that 'plan' defaults to pay-as-you-go when omitted and ties it implicitly to list_plans. This is genuine added value over the schema's bare 'Optional plan name or ID' 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 first sentence states a specific verb and resource ('Creates a space for one capture'), and the resource 'space' is clearly distinct from sibling resources like tours. 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?

The description gives strong conditional workflow guidance: non-paying accounts get a free private preview, otherwise the tool returns a Stripe Checkout link and the caller should then invoke wait_for_payment, a named sibling. It does not, however, differentiate from create_tour or explain edge cases such as re-invocation.

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?

With no annotations, the description carries the full behavioral burden, and it discloses almost none of it. It hints the tour is 'private' but says nothing about permissions, what state is created, idempotency, or error behavior on an invalid scene_id.

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 sentence, front-loaded with the core action and tight throughout. Every clause earns its place by naming a sibling or the required input source.

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

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

For a mutation tool with no annotations and no output schema, the description covers the workflow well but omits any behavioral or return context. Adequate to place the tool, insufficient for an agent to predict the result of calling it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 33% (only scene_id is documented), so the description must compensate. It effectively maps the kind enum via 'guided tour or scavenger hunt', but adds nothing for title, which is undocumented in both places.

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 ('Starts') plus resource ('a private guided tour or scavenger hunt') and scope ('on a space'). It also names the relevant siblings (find_tour_spaces, draft_tour, save_tour), letting an agent place it in the workflow 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?

It clearly states the precondition (a space obtained from find_tour_spaces) and the follow-up tools (draft_tour or save_tour), which is strong contextual routing. It stops short of an explicit when-not (e.g., when to use save_tour directly instead).

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?

With no annotations, the description carries the full burden and does well: it discloses the asynchronous model ('Returns at once'), the AI agent that views photographs, and that it 'places everything and saves' (a mutation). Permissions, overwrite semantics, and failure modes are left unstated, keeping it short of 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?

Front-loads the core action and ends with the essential follow-up call. The parenthetical catalog of content types is long but informative; the piece is one dense flow rather than broken into scannable units.

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

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

For a two-parameter mutation with no annotations and no output schema, the description supplies the async behavior, the follow-up call, and the content scope an agent needs. Return-value detail is minimal, but 'Returns at once' plus the wait_for_tour pointer covers the essentials.

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 'request' parameter has no schema description, and the description compensates by enumerating what a plain request can express (stops/text, hidden objects/clues, models, effects, sound, music, looks with transitions and skies). The tour_id parameter is already documented in the schema as a 12-hex ID from create_tour or list_tours.

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: it asks the site's tour agent to 'write or rework the tour' from a plain request. It differentiates itself from the mechanical create_tour by emphasizing AI-authored content, though it never names siblings 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?

Gives a clear next-step handoff ('Returns at once; then call wait_for_tour') and implies usage via 'write or rework the tour from a plain request.' It does not explicitly say when to prefer this over create_tour or save_tour, so routing is only partly disambiguated.

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?

With no annotations, the description carries the full disclosure burden. It does usefully describe the result scope (own finished spaces plus public museums/temples/tombs/gardens), which is genuine behavioral context, but says nothing about pagination, result ordering, authentication requirements, or what happens with an empty query.

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?

Compact: one scope-defining clause followed by a colon-enumerated result set, then a short usage fragment. Front-loaded and free of filler, though the trailing fragment is slightly clipped.

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 single-optional-parameter search tool with no output schema and no annotations, the description covers the result domain but leaves gaps on optionality, empty-query behavior, and result shape that an agent would need to call it confidently.

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% — the only parameter is typed as a bare string with no description. The description partially compensates by clarifying that the query matches against title words, but it doesn't say whether the parameter is optional or what an omitted query returns.

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 action and resource scope: spaces eligible to host a guided tour or scavenger hunt, split into the user's finished spaces and the site's public spaces. An agent understands the domain of results, though it never names a sibling tool (e.g. get_tour, search_models) to distinguish itself.

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?

"Search by words in the title" implies the query usage but gives no explicit when-to-use or when-not-to-use guidance, no alternative named for browsing versus searching, and no indication of whether the tool is a prerequisite step for create_tour.

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?

With no annotations, the description carries the full burden. It usefully discloses that validation runs first and that completion is asynchronous via email, but omits what happens when a file is incomplete, whether submission is reversible, and any auth or rate-limit 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?

Two tight sentences, front-loaded with the validation-and-submit action and followed by the notification outcome. No filler or redundancy.

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 finalize-style tool with rich schema coverage and no output schema, the description covers the essential arc: check, submit, notify. The remaining gap is failure behavior and irreversibility, which is minor but real.

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 four parameters are already documented in the schema, including the output enum and submit default. The description adds no parameter-level detail beyond that, 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: it validates uploaded files and submits the space for processing. That is clearly distinct from upload_files and space_status, though the description never names those siblings to make the distinction 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?

The workflow position is implied by 'every uploaded file' and 'submits the space', suggesting it is the final step after uploading. However, it never states when to call it versus upload_files or space_status, nor what to do if validation fails.

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?

With no annotations, the description carries the full burden. It usefully discloses the shape of the returned document and, importantly, that a revision accompanies it — critical context for a subsequent save_tour. It says nothing about read-only nature, auth requirements, or failure modes (missing/expired tour_id), leaving obvious gaps.

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 tight sentence with the resource front-loaded and the payload fields parenthetically enumerated. Every clause carries weight (fields + revision + intended consumer), though the field list borders on noise for an agent that will simply read the JSON.

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 exists, so the description must summarize the return value — it does so by naming the document sections and the revision. For a single-parameter read tool with no annotations this is nearly complete, lacking only error/prerequisite detail.

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?

Only one parameter (tour_id) and schema description coverage is 100%, including the 12-hex-character format and its source (create_tour/list_tours). The description adds nothing beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource and payload ('The tour as JSON (stops, objects, effects, looks, skies)') plus the accompanying revision field, which distinguishes it from list_tours (enumeration) and save_tour (mutation). The retrieval verb is implicit rather than stated, but the 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?

'for editing with save_tour' implies the read-modify-write workflow and points at the consuming sibling, which is useful implied usage. However, it never states when to use this versus list_tours or draft_tour, nor any prerequisite (e.g. that the revision must be passed back to save_tour).

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?

Without annotations, the description must carry the full burden. It discloses the two-step flow and the security note 'Never ask for a password,' which is valuable. It does not cover edge cases like failure modes, rate limits, or what happens after linking, leaving some behavioral gaps.

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 tightly written sentences with zero waste: purpose first, then the interaction flow, then a critical security note. The description is front-loaded and 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?

Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description adequately explains the linking process and the need to call again after approval. It could mention what happens after linking or error handling, but for an agent to invoke correctly, it is nearly 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 single parameter `link_code` is fully described in the schema (100% coverage), so the baseline is 3. The description adds the context to call again with the link code, but does not provide additional syntax or format details 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 a specific verb ('Links') and resource ('this agent to the person's account'), making the purpose clear. It does not explicitly name the sibling tool `unlink_account` as the alternative, but the opposite action is evident, so an agent can distinguish it without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the usage: call to get a link, have the person sign in and approve, then call again with the link code. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions, leaving the agent to infer the 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?

No annotations are provided, so the description carries the full behavioral burden. It does not state that this is a read-only, side-effect-free operation, nor anything about permissions, freshness of prices, or return shape. The second sentence hints at a free preview plan but is too oblique to count as useful behavioral disclosure.

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 first sentence is reasonably front-loaded and informative. The second sentence is cryptic and arguably belongs to a different tool's concerns (publishing/keeping a space), so it dilutes rather than 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 no output schema, no annotations and zero params, the description needs to stand alone. It sketches the content (plans, prices, current plan) but does not describe the return structure or ordering, and its second sentence adds confusion rather than completeness.

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 and the schema is empty, so there are no parameter semantics to explain. Baseline 4 applies; the description correctly implies no inputs are required.

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 conveys that this returns hosting plans with prices and the account's current plan, which is the gist of listing plans. However, it never states a clear verb+resource ('list plans') and its second sentence drifts into a different topic about a free preview space, muddying what the tool actually returns. No sibling directly overlaps, so distinguishing isn't the issue — specificity is.

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?

'Show them when the person wants to publish it or keep it' gestures at a trigger condition, but it is vague and only covers one scenario. No mention of alternatives (e.g. where to check account billing versus plan catalog) and no explicit 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?

No annotations are provided, so the description carries the full behavioral burden. It notes the result includes tours/hunts 'with their links', but says nothing about pagination, ordering, auth requirements, or whether draft tours are included, which matters given siblings like draft_tour and finish_upload.

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?

It is a single short phrase with no filler, but it is under-specified rather than well-structured. Brevity here reflects missing information rather than disciplined editing.

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 no annotations, the description must explain what comes back and any behavioral constraints. It only hints at links and omits return shape, pagination, and scope (e.g., whether archived or draft tours are included), which is insufficient for an agent to call it reliably.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has zero parameters, so there are no parameter semantics to document; the baseline for a no-param tool is 4. The description correctly implies the tool takes no filtering input.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (tours and scavenger hunts on the account) and implies a listing action, but there is no explicit verb. An agent can infer it returns the account's tours, yet the phrasing is a noun clause rather than a stated operation, leaving the action implicit.

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 the many siblings such as get_tour, list_plans, or find_tour_spaces. The tool appears to return all account tours, but nothing states exclusions or alternative selection criteria.

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?

No annotations are present, so the description carries the full disclosure burden. It implies a write/overwrite of an existing tour but never says whether previous content is replaced, whether permissions are required, or what happens on conflict, which is a notable gap for a save/mutation 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?

Two tight sentences that front-load the core action and then the payload provenance. Little waste, though the phrasing is slightly terse given the nested experience object.

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 no annotations, the description should do more. It usefully explains where the experience JSON and model URLs come from, but the nested experience structure, overwrite behavior, and failure modes remain 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 only 33% (title and experience are undocumented), so the description must compensate. It does add provenance for 'experience' (JSON from get_tour, models from search_models or .glb URLs), but it says nothing about the shape of the experience object or the optional title, leaving part of the gap unfilled.

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 (Saves) and resource (a tour) and scopes it as 'edited by hand', which hints at its place relative to create_tour/draft_tour. It also names the source of its main payload (get_tour), though it does not explicitly name what it is not for.

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 a workflow: take experience JSON from get_tour, edit it, and supply model URLs from search_models or any .glb address. That gives real context for how to use it, but there is no explicit when-to-use-vs-alternatives guidance against siblings like create_tour, draft_tour, or finish_upload.

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?

With no annotations, the description carries the full burden, and it does disclose the return payload ('each model's size and url'), which is genuinely useful since no output schema exists. However, it says nothing about pagination/limit behavior, result ordering, or whether the library is remote or rate-limited, leaving meaningful behavioral gaps for an unannotated 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?

Two compact sentences with no filler: the first establishes what is searched, the second what comes back. The purpose is front-loaded ahead of the return detail.

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?

The description partially covers the missing output schema by naming the returned fields, and the tool is simple (two flat params, no nesting). But with 0% schema coverage and no annotations, the undefined query/limit semantics leave the definition short of what an agent needs to invoke it confidently.

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 compensate for both parameters, and it does not. It never explains what 'query' matches (name, tag, period, geometry?) or what 'limit' controls, so an agent gets no semantic guidance beyond the bare parameter names.

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 (searches) and resource (library of ready-made 3D models), and the parenthetical examples (statues, amphorae, temples, furniture, animals, props) make the corpus unambiguous. It does not explicitly differentiate from siblings, but none of the listed siblings are model-search tools, so the risk of confusion is low.

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 statement of when to use this tool versus alternatives, no prerequisites, and no indication of when it would be the wrong choice. Usage is only implied by the purpose sentence.

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?

With no annotations, the description carries the full burden and does well: it discloses a non-obvious side effect (returning a Stripe Checkout link instead of simply flipping visibility) and a consent requirement ('Ask the person first'). It still omits reversibility, permission requirements, and error behavior, keeping it 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 sentences, each carrying distinct load: what the tool toggles, the consent instruction, and the payment edge case. The primary purpose and the public/private semantics 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 two-param mutation tool with no annotations and no output schema, the description supplies the critical missing context: the side-effect return value and the consent requirement. Only permission/error behavior is unaddressed, which is a minor gap.

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%: space_id is documented in the schema, but the 'public' boolean is bare. The description compensates by defining exactly what each boolean value means ('anyone with the link' vs 'only the owner'), adding real meaning 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 specific verb+resource ('Makes a ready space public... or private') and defines both target states inline ('anyone with the link' vs 'only the owner'). No sibling tool in the list overlaps with visibility toggling, so the agent can route here unambiguously.

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 one behavioral precondition ('Ask the person first') and a state precondition ('a ready space', 'until hosting starts'), which implies when the tool applies. However it never states when not to use it or names an alternative path, so usage is only partially guided.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses the link-based, never-listed semantics of public sharing and the consent requirement, but says nothing about permissions, reversibility, or side effects on existing shares.

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 plus one short imperative sentence. Zero padding and the primary behavior (visibility change) is front-loaded ahead of the optional rename.

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

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

For a mutation tool with no annotations, no output schema, and partial schema coverage, the description covers both actions, the sharing semantics, and consent. Missing only permission/error behavior, which is minor given no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 33% (only tour_id is documented), so the description must compensate. It does: 'makes a tour public or private' clarifies the public boolean, and 'optionally renames it' clarifies the title parameter, covering both undocumented fields.

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 specific verbs (makes public/private, optionally renames) and the resource (tour), with a precise clarification of what 'public' means: 'anyone with its link, never listed.' This is clear but does not explicitly differentiate from a potentially overlapping sibling like set_visibility.

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 (toggling tour visibility / renaming), and 'Ask the person first' gives a real consent precondition. However, it never routes the agent among alternatives such as set_visibility or draft_tour, so selection guidance 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?

No annotations are provided, so the description carries the full burden. It does disclose one genuinely useful behavioral trait — the link is returned 'when ready', implying asynchronous readiness — but says nothing about permissions, whether the call blocks, or polling expectations, which matters given a wait_for_* sibling exists.

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 sentence, front-loaded with the primary scope (one space) before the fallback (every space). Every clause earns its place; no boilerplate or repetition.

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 no annotations, the description should carry more. It gestures at return content (status, link when ready) but does not enumerate possible status values or indicate freshness/polling behavior, leaving an agent to guess what a 'status' response means.

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 would be 3, but the description adds meaning beyond the schema: omitting space_id returns every space on the account, a scoping behavior the schema does not state. It does not, however, add format guidance beyond the schema's '12 hexadecimal characters' note.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource and scope: the status of a single space, or of every space on the account. It is distinguishable from siblings like create_space or find_tour_spaces by naming the status/link read, though it never explicitly contrasts itself with any sibling.

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?

'Status of one space, or every space' implies the usage pattern (supply space_id for one, omit it for all), but this is left to inference rather than stated. There is no when-to-use guidance relative to alternatives such as get_tour or wait_for_tour, and no 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?

No annotations are provided, so the description carries the entire behavioral burden. It does not disclose whether unlinking is reversible, what access or state is lost, whether confirmation or specific permissions are required, or what the caller receives on success or failure — significant gaps for a lifecycle-mutating operation.

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 no filler or redundancy — nothing to trim. It is appropriately sized for a zero-parameter tool, though its brevity is part of why behavioral detail is missing.

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

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

For a zero-param tool with no annotations and no output schema, the description should at least convey consequences and reversibility, since the agent has no other source for them. As written, an agent cannot predict the effect of calling it beyond the literal meaning of 'unlink'.

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 per the rubric this is the baseline 4. There are no arguments whose meaning the description could clarify, and schema coverage is effectively complete.

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 (unlink) and resource (account) with the agent as subject, so the operation is unambiguous. It does not explicitly reference its inverse sibling link_account, but the naming pair makes the distinction obvious 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?

No guidance on when to unlink versus when to keep or re-link, no prerequisites (e.g., must be currently linked), and no mention of the link_account sibling that an agent would pick instead when going the other direction. The agent must infer all usage 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?

With no annotations, the description carries the full burden and does disclose meaningful mechanics: this initiates a resumable upload and returns PUT destinations rather than uploading bytes itself. It does not state permission requirements, size limits, or auth needs, but the two-phase behavior is unusually well surfaced.

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, front-loaded with the core action and the return value, followed by a routing rule for the out-of-scope case. Every sentence earns its place, though the closing 'give them the space's page' is slightly vague.

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 2-param mutation tool with no annotations and no output schema, the description conveys the return shape (PUT targets). But it leaves the completion path (finish_upload), auth/permission prerequisites, and resumable protocol constraints unaddressed, which the agent likely needs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50% (space_id documented; file name/size only partially). The description adds useful meaning about which files qualify (photos/video the person shared), but says nothing about the required name/size fields or the array structure 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?

States a specific verb and resource ('Starts resumable uploads for capture files') and even implies the initiation role versus a completion step via 'Starts... returns where to PUT'. It does not name the sibling finish_upload, so the distinction from that adjacent tool is left to inference.

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 when-to-use condition ('capture files you hold... the person shared with you') and an explicit when-not with an alternative path for files on the person's own device. However, it omits the natural next step in this API (finish_upload) that the agent needs to complete the flow.

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?

With no annotations, the description carries the full burden and does disclose the two most important traits: the 25-second blocking cap and the fact that the call is a poll that must be repeated. It does not say what a completed vs timed-out call yields, but the retry semantics are the key behavior and are stated.

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, the timeout duration front-loaded, and the polling rule last. No filler or restatement of the name.

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

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

For a single-parameter wait/poll tool with no annotations and no output schema, the essential information (duration, retry behavior, applicable scenarios) is present. Only the outcome of a completed or timed-out wait is left unspecified, a minor gap.

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?

One parameter with 100% schema coverage; the schema already documents space_id as a 12-hex-character ID sourced from create_space or space_status. The description adds nothing 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 (waits), a bounded scope (up to 25 seconds), and the exact resource/event (the person finishing payment in Stripe Checkout). The dual trigger contexts (first payment or publish free preview) and the name versus the sibling wait_for_tour make it unambiguous which wait tool to pick.

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 when-to-use context (after checkout, either for a first payment or to publish a free preview) and an explicit polling instruction: 'Call it again to keep waiting.' It stops short of naming when not to use it or pointing at wait_for_tour as the alternative, so it is not a full 5.

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?

With no annotations, the description carries the full burden, and it does disclose the key behavioral traits: a bounded 25-second wait and idempotent re-invocation to continue waiting. It does not clarify whether the call is read-only, whether it blocks, or what distinguishes a timeout result from a completed one.

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, zero waste, with the most decision-relevant fact (the 25-second bound) front-loaded and the retry rule immediately after.

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 polling tool with no output schema, the description supplies the wait bound, the polling pattern, and the general return content ('summarizes the tour'). A brief note on what comes back when the wait times out would make it 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 the single tour_id parameter is documented in the schema, including its 12-hex-character format and its origin (create_tour or list_tours). The description adds nothing about the parameter, 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?

Names a specific verb and resource ('waits ... for a draft to finish') plus the side effect of summarizing the tour, so the agent knows exactly what this does. It does not explicitly differentiate itself from get_tour, which also retrieves tour state, so it falls short of full sibling disambiguation.

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 real operational guidance: the 25-second ceiling and the instruction to 'call it again to keep waiting' describe the intended polling loop. It stops short of saying when to choose this over get_tour or when to give up polling entirely.

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