Awning

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

Annotations already signal destructive and non-read-only behavior. The description adds meaningful behavioral context beyond that: cancellation is governed by the business policy, user confirmation is required, and the user must be informed of late fees. It aligns with destructiveHint and idempotentHint, with no contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with no filler. It front-loads the primary action and policy immediately, then states the required user-facing steps. 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?

The description covers the core action, policy context, confirmation requirement, and fee disclosure, which is adequate for a simple cancellation. However, it lacks guidance on manage_token, what happens after cancellation (e.g., refunds or side effects), and does not distinguish itself from owner_cancel_booking. Given no output schema, these gaps make it only partially 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 0%, and the description adds no meaning for the three parameters. It never explains booking_id, reason, or manage_token, leaving manage_token particularly ambiguous. With no parameter descriptions in the schema and no compensation in the description, an agent has insufficient semantic grounding.

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 clear, specific action ('Cancels a booking') and the resource affected. It implies a customer-side cancellation via 'under the business cancellation policy' and 'Confirm with the user first,' but it does not explicitly distinguish this tool from the sibling owner_cancel_booking.

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 intended usage is implied by the action itself: use when a booking must be cancelled. It also gives a key precondition and follow-up step ('Confirm with the user first and tell them whether a late fee applies'). However, it gives no explicit guidance about when not to use it or which sibling alternative to prefer.

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 mark it as non-read-only, idempotent, and non-destructive. The description adds value by emphasizing that it creates a real reservation (real-world consequence) and requires explicit user confirmation, which is critical context beyond the annotations. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no redundancy, and the core purpose is front-loaded. Every clause adds essential usage information, making it highly efficient for an agent to parse quickly.

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 tool with nested objects and no output schema, the description covers the essential usage: the hold context, confirmation requirement, contact requirements, and idempotency. It does not explain the response format or the fate of the hold, but these are not critical for invocation. Overall, it is complete enough for correct use.

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

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

Schema coverage is low (33%: only idempotency_key has a description). The description partially compensates by explaining the idempotency_key reuse and the name/contact requirements for the customer object. However, it does not clarify hold_id, address, note, or intake_answers beyond what the schema shows, leaving gaps for those parameters.

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 ('Creates a REAL booking from a hold'), which clearly distinguishes it from sibling tools like create_hold and cancel_booking. The emphasis on 'REAL' and 'from a hold' removes ambiguity about its role in the booking workflow.

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 explicit preconditions: 'Call only after the user explicitly confirmed time and price' and the requirement for name/contact unless signed in. It also advises on idempotency key reuse for retries. It does not explicitly name alternative tools, but the 'from a hold' context makes the workflow clear.

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 provide generic flags (readOnly=false, idempotent=false, destructive=false), so the description carries the behavioral burden. It adds meaningful traits: the hold lasts 10 minutes, the price is fixed, and explicit user consent is required before proceeding. It does not contradict the annotations, though it does not mention expiry side effects or return shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no filler. The first sentence states the core behavior, and the second provides parameter-mode selection and the required follow-up step. Information 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?

For a tool with 10 parameters and no output schema, the description covers the main invocation patterns and the surrounding workflow. It has some gaps around optional parameters like `qty`, `tickets`, and `resource_id`, and it does not describe the tool's return value, but it is sufficient for an agent to correctly initiate the hold and proceed to the confirmation step.

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 only 40%, but the description compensates for the central time parameters by mapping `start`, `session_id`, and `from`/`to` to slot, session, and rental offerings. It does not explain `qty`, `party_size`, `tickets`, `resource_id`, or `offering_id`, so compensation is partial, but the most important usage distinctions are provided.

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 uses a specific verb and object: 'Reserves the chosen time, seats or units for 10 minutes and fixes the price.' It clearly identifies the action and its scope, and its mention of create_booking helps distinguish this hold operation from the final booking step.

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 explicit parameter-mode guidance: 'Pass `start` (slots), `session_id` (sessions) or `from`+`to` (rentals).' It also prescribes the exact user-facing workflow: show time, price, and cancellation policy, then wait for an explicit yes before create_booking. This leaves little ambiguity about when and how to use the 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 mark the tool as read-only, so the description's main contribution is mode-specific behavior: slots returns start times, sessions returns classes with seats left, and period checks from/to and units left. It adds useful behavioral context beyond the annotations, though it omits response shape, pagination, and error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler: the first states scope, the second packs three mode behaviors into a readable semicolon list, and the closing directive tells the agent when to prefer this tool. 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 7-parameter tool with no output schema, the description gives useful mode-level expectations but omits how modes are selected, the role of party_size, and return-shape details. It is workable for a straightforward query but not fully self-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 descriptions already cover from/to, qty, options, and resource_id, and the description adds mode semantics that clarify qty and from/to in period mode. However, it never explains how a caller selects a mode, nor does it describe the purpose of party_size and offering_id, leaving two schema-undocumented parameters unsupported.

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

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

The description clearly identifies an availability query for a single offering and enumerates three modes with concrete return content: start times, classes with seats left, and units left. It stops short of a 5 because it does not name a sibling tool to differentiate against, only contrasting with 'guessing from opening hours.'

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 line 'Always call this instead of guessing from opening hours' gives a strong, explicit directive about when this tool is the source of truth for availability. However, it does not explicitly state when not to use it or mention alternative sibling tools such as owner_get_schedule or search_businesses.

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 the description adds useful auth-related behavior beyond that: the token is optional under signed-in ownership and must come from manage_url when used. It does not describe error or response behavior, but for a simple read-only tool this is acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no filler. The core purpose is front-loaded, and the auth nuance follows immediately. It does not repeat schema or annotation information.

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

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

For a two-parameter read-only status tool, the description covers the essential purpose and the key auth distinction. The return concept is conveyed by 'Status of a booking,' and the required parameter is inferable. It is slightly thin on response details, but those are not critical for a simple status lookup.

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 for parameters. It adds meaningful meaning to manage_token by defining its source and optionality. However, booking_id — the only required parameter — is not explicitly explained beyond its name, and the description never states its role in identifying the booking.

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 'Status of a booking,' which identifies the resource and the read-only nature of the operation. It is distinct from siblings like cancel_booking and create_booking. The lack of an explicit verb such as 'get' or 'retrieve' is the only minor 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?

The description clearly explains two invocation contexts: pass manage_token from manage_url, or omit it if the signed-in user owns the booking. However, it does not name alternative tools or explicitly say when not to use this one, so the 'vs alternatives' aspect of usage guidance is missing.

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 agent knows this is a safe read operation. The description adds valuable behavioral context by specifying exactly which fields the response includes (prices, booking rules, cancellation policy, etc.), which goes beyond the annotation. No contradiction or missing critical behavior for a simple getter.

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 that communicates the scope and content efficiently. No filler words, and every listed field adds value for an agent deciding whether to call this tool. It's concise without being terse.

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-only getter with no output schema, the description is fully sufficient. It tells the agent what it returns and what it applies to. Annotations cover safety, and the parameter is self-documenting in the schema. Nothing needed for a correct invocation 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?

The schema already provides full parameter documentation with a description 'business_id or slug' at 100% coverage. The description does not add any additional meaning about the parameter itself, which is acceptable given the schema coverage. Baseline 3 applies because 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 states a clear verb ('get') and a specific resource ('business details'), then enumerates the exact content: offerings, prices, extras, booking rules, intake questions, hours, cancellation policy, contacts. This differentiates it from sibling tools like search_businesses (searching) or op_businesses (operator listing) without ambiguity.

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 for a single business by saying 'one business' and listing the full card contents. It doesn't explicitly exclude alternatives or name when-not-to-use, but the context is clear enough that an agent would know to use this for fetching a single business rather than searching or listing. No explicit comparison, but the purpose is self-evident.

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 and idempotentHint=true, and the description aligns with those. It adds value by disclosing the behavioral distinction between local sign-out and global sign-out with everywhere=true, which the annotations do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler. The core behavior is front-loaded, and the optional parameter behavior is explained in the second sentence. Every word 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 simple logout tool with one optional parameter agreed with annotations, the description covers the essential behavior and scope. The destructive and idempotent hints handle safety expectations, and no return schema is needed for a likely void operation.

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

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

Schema coverage is 0%, so the description must carry the meaning of the only parameter. It does so explicitly: 'everywhere=true' signs out of every assistant and device. This fully compensates for the schema's lack of description.

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

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

The description uses a specific verb ('Signs out') and identifies the exact resource ('Awning in this assistant'), which clearly distinguishes it from all sibling tools like booking and business management operations. It goes beyond the title by specifying the local scope and the global variant.

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 makes the usage context clear: it signs the user out of Awning within this assistant, and only signs out everywhere when everywhere=true. It does not explicitly mention alternatives or when-not-to-use, but the tool's purpose is self-evident and there are no logout-related 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 declare readOnlyHint=true, and the description adds a meaningful behavioral detail beyond that: the tool will ask the user to sign in to Awning if they are not authenticated. This is useful interactive context that the annotations do not provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler. The core purpose is front-loaded, and the authentication note in the second sentence earns its place as a prerequisite.

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 one optional enum parameter, the description covers the essential scope and auth behavior. It does not describe return values or the exact effect of 'period', but the schema's enum values mitigate that gap for a low-complexity 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?

There is one parameter, 'period', with an enum of 'upcoming', 'past', and 'all' but no schema description. The description never mentions the parameter or explains how it filters results, so the agent must infer its meaning entirely from the parameter name and enum values rather than from any tool-level guidance.

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 resource ('the signed-in user's bookings') and scope ('across all businesses'), making it clear this is a customer-facing list tool rather than an owner or single-booking tool. It uses an implied verb rather than an explicit one like 'lists', but the meaning 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?

The description conveys when to use it: when the signed-in user's bookings across all businesses are needed, and it notes an authentication prerequisite. It does not explicitly name alternatives or state when-not-to-use scenarios, leaving some routing decisions 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?

The description discloses the dual read/update behavior, which adds context beyond the annotations' readOnlyHint=false. However, it does not state that an empty call likely performs the read while supplying parameters performs the update, nor does it mention any side effects or authorization nuances. No contradiction with annotations is present.

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 with no filler, front-loading the read action and then bundling the updateable fields. Every word contributes to the meaning, and the enum clarification is embedded naturally.

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 is adequate for a simple profile tool but leaves gaps: it does not explicitly explain that calling with no parameters reads while calling with parameters updates, and with no output schema it does not describe what a successful read or update returns. These are material for an agent deciding how to invoke and interpret the tool.

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

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

With 0% schema description coverage, the description carries the burden of explaining parameters, and it names all four: name, phone, language, and contact channel via 'where to send notifications (email or telegram).' It clarifies the enum values and the purpose of each field, though it omits formats like language codes or phone number syntax.

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 uses a specific verb and resource: 'Read the signed-in user's profile, or update name, phone, language or where to send notifications.' It clearly identifies the object (the current user's profile) and the two distinct actions. This sufficiently distinguishes it from siblings like my_bookings and logout.

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 explicit guidance is provided about when to use this tool versus alternatives. The phrase 'signed-in user's profile' implies it targets the current user, but there is no mention of alternatives, exclusions, or preferred context among the many sibling 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 declare readOnlyHint=true, and the description aligns with that by describing a read-only analytics query. The description adds valuable behavioral context beyond the annotation: it explains that 'assistants do not run scripts, so only this part shows them', which is a subtle data-behavior detail an agent needs to interpret results correctly. It also clarifies the two data sources (Umami vs server-side), which is behavioral context not present in the schema or annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the most important constraint ('Only for the Awning team'). It packs a lot of information into a few sentences without redundancy. The structure is a bit run-on and could be clearer with punctuation, but every sentence earns its place 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?

Given the tool's simplicity (one optional parameter, no output schema), the description covers the essential context: audience restriction, data sources, metrics, and summarization instruction. It doesn't describe the exact output format, but with no output schema and a read-only analytics tool, the description's guidance on how to interpret and summarise is sufficient for an agent to invoke it correctly. Minor gap: it doesn't explicitly state what the response looks like, but the description's focus on interpretation compensates.

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 the single 'days' parameter. The description implies the time window ('over the last days') and the instruction to compare with the previous period, which gives the agent a sense of what 'days' controls. However, it doesn't explicitly state that 'days' is the lookback window or describe its format/range, leaving some inference required. Still, with only one parameter and a clear context, the description provides enough semantic grounding.

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

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

The description clearly states the tool is for the Awning team and explains what it reports: website performance over recent days, with two distinct data sections (people and all_visits). It names specific metrics (top pages, sources, channels, countries, devices) and distinguishes the two data sources (Umami vs server-side counting). This is a specific verb+resource with clear scope, and it differentiates itself from the sibling tools, which are mostly booking/business operations.

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 explicitly restricts usage to the Awning team ('Only for the Awning team'), which is a clear when-to-use gate. It also explains the difference between the two data sections and instructs the agent on how to summarise results ('compare with the previous period and name the share of assistants'). This is explicit guidance on how to use the tool and what to do with its output.

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 description adds useful context beyond the readOnlyHint annotation: the Awning-team scope restriction and the content detail (owner contacts and warnings). It does not contradict the annotation, since a queue view is a read operation. However, it leaves ordering, pagination, and the meaning of 'warnings' undisclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero redundancy; the scoping constraint is front-loaded and the content summary is maximally efficient. Every word contributes meaning.

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 one optional enum parameter and no output schema, the essential context — audience, resource, and included data — is present. Missing details such as ordering or the definition of 'warnings' are minor for a queue-view tool whose safety profile is already covered by readOnlyHint.

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 0% schema description coverage, the description carries the full burden for explaining the status parameter, yet it never mentions filtering by status or how the submitted/approved/rejected values interact with the queue. The bare enum in the schema is self-explanatory, but the description fails to clarify, for example, whether approved applications remain in the queue.

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

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

The description identifies the resource ('business applications') and the operation via the noun 'queue', which strongly implies listing/retrieving applications. It is specific enough to be distinguished from sibling tools like op_decide_application (decision action) and op_leads (different resource). However, there is no explicit verb such as 'list' or 'get', so the operation must be inferred 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?

The only usage constraint is the audience restriction 'Only for the Awning team', which gives the agent a clear access boundary. There is no explicit statement of when to use this tool versus siblings such as op_decide_application or op_leads, so routing is left to inference rather than being spelled out.

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

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

Annotations declare readOnlyHint: true, and the description does not contradict that. It adds behavioral context about the link selection (public vs private preview) and the statuses included, but doesn't describe pagination or other side effects. Since read-only is already covered, this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, with scope stated first, then output details, then filtering. No redundant words, and the most important scoping constraint is front-loaded.

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 listing tool with two optional parameters and no output schema, the description covers the key aspects: what is returned, filtering, and link behavior. It doesn't differentiate from search_businesses, which could be a minor gap, but overall it's sufficient for an agent to call it 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 0%, so the description must explain parameters. It explicitly says 'Filter by status or by part of the name', which maps to the query and status parameters. It explains their purpose clearly, though it doesn't detail enum values, which are in 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 clearly states it lists every business on Awning with status, owner, and link, and explicitly scopes it to the Awning team. This distinguishes it from get_business (singular) and search_businesses (likely filtered search), making the purpose 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?

The description implies it's for listing all businesses with optional filters, but does not explicitly compare to sibling tools like search_businesses or get_business. It gives clear context on filtering but no exclusions or when-not-to-use guidance, so it's slightly below 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 only provide generic readOnly/idempotent/destructive hints, so the description carries the burden of explaining behavior. It discloses that this is a non-read-only action with external confirmation and a server-side prerequisite, adding meaningful context beyond the annotations.

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 convey audience, action, required user steps, and prerequisite. No filler or redundancy; the most important scoping constraint is front-loaded.

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 tool with no output schema, the description gives the essential flow and prerequisite. It does not explicitly describe the response/returned link, but the action and user steps are sufficiently stated for an agent to invoke and explain the tool.

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

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

The input schema has no parameters and schema description coverage is 100%, so there is nothing the description needs to add. With zero parameters, the baseline is 4 and the description does not fail to compensate for any schema 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?

The description states a specific action ('Create a link to bind your Telegram to your signed-in operator account') with a clear resource and outcome. This purpose is unique among the sibling tools, none of which concern Telegram linking, so an agent can distinguish it without opening other definitions.

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

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

The description gives clear context and prerequisites: it is 'Only for the Awning team,' the operator must open and confirm the link, and an administrator must pre-approve the numeric ID. It does not name alternative tools or explicitly say when not to use it, but the scope and steps are enough to guide correct use.

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, so the description adds value by explaining the concrete effect: approving publishes the business. It also notes that a rejection note is visible to the owner. However, it doesn't discuss reversibility, other side effects, or authorization details beyond the team restriction.

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 that front-loads the team restriction and packs both decision effects. No fluff or repetition of the title. It earns a high score for brevity and structure.

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 decision tool with no output schema, the description covers the key behavioral outcome (publishing on approve) and the note requirement on reject. Missing details include how to obtain an application_id, whether reject has other consequences, and any idempotency or retry implications. Overall adequate but not thorough.

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 0% schema coverage, the description must compensate. It does clarify the decision enum (approve/reject) and the note parameter by stating reject requires a note the owner will see. application_id is left undocumented, and no format or example is given. The partial explanation raises it above the baseline for low coverage but is incomplete.

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

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

The description clearly states the tool approves or rejects an application and specifies the effect of each decision ('approve publishes the business; reject needs a note'). It distinguishes from sibling decide tools like op_decide_lead and owner_decide_booking by implying this is about business applications, though it doesn't explicitly name the resource type.

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 includes a restriction ('Only for the Awning team') but gives no guidance on when to use this tool versus alternatives like op_decide_lead or owner_decide_booking. It also implies that reject requires a note, but this is more of a parameter requirement than a usage guideline. No exclusions or alternative routing are mentioned.

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 description discloses concrete behaviors: invite sends an email to the business, close drops the enquiry with an optional note. This adds context beyond the annotations (readOnlyHint=false, destructiveHint=false), clarifying the effects of each action. It does not contradict any annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences that front-load the team restriction and clearly state the two actions and the note's purpose. There is no unnecessary wording.

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

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

For a simple 3-parameter tool with no output schema, the description adequately covers the actions and parameters. However, it does not mention what the tool returns or any error conditions, which could be relevant for an agent deciding how to handle the result. Given the simplicity, it is sufficient but not 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?

With 0% schema coverage, the description compensates by explaining the decision enum values ('invite' and 'close') and the note parameter ('optional note for us'). lead_id is implied as the enquiry identifier but not explicitly defined; however, its purpose is obvious from the context.

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

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

The description clearly states the tool's two actions: invite (emails the business) and close (drops the enquiry), and names the resource (enquiry). It is specific with a verb and resource, but does not explicitly differentiate from sibling tools like op_decide_application, though the restriction to 'Awning team' and the lead context help distinguish 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 only guidance is the restriction 'Only for the Awning team', which limits who should use it but does not explain when to use this tool versus alternatives such as op_decide_application or other lead-related tools. No exclusions or conditions are provided beyond the team restriction.

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 covers safety, and the description adds useful context about the exact subset of businesses and a team restriction. It does not describe the effect of the status parameter or what the response contains, but it does not contradict 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?

Two short sentences, with the most important restriction ('Only for the Awning team') front-loaded. Every sentence adds relevant scope information 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?

For a one-optional-parameter read-only tool, the description conveys the core data scope, and readOnlyHint covers safety. However, there is no output schema and the description does not explicitly state the return format or explain how the status parameter behaves, leaving some inference required.

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%, and the description says nothing about the optional status parameter or how its enum values filter results. The enum values are self-explanatory, but no relationship between the described leads and the status stages is provided.

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

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

The description identifies a specific resource (website enquiries for the Awning team) and adds a distinguishing filter (businesses that have not filled the questionnaire), separating it from siblings like op_applications. However, it lacks an explicit verb such as 'lists' or 'returns', so the action must be inferred.

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

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

The phrase 'Only for the Awning team' provides a clear audience/scope restriction, and the 'not filled the questionnaire yet' condition implies when this leads view is relevant. It does not name alternatives or state when not to use this tool, so guidance is implicit 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 convey destructive and non-read-only behavior. The description usefully clarifies that the operation hides rather than deletes, and adds real-world trigger examples. However, it does not disclose consequences such as reversibility, impact on existing bookings, or what clients will see afterward.

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, tightly written sentence that front-loads the audience restriction, states the core behavior, and provides examples. Every phrase earns its place with no redundancy or 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 tool with only two parameters, no output schema, and informative annotations, the description provides a solid operational picture: who may use it, what it does, and when it is appropriate. It could still mention downstream effects, but given the low complexity, it is mostly 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 0%, so the description must compensate for parameter documentation, but it does not explain business_id or reason beyond the raw schema. The parameter names are self-explanatory to some degree, but the reason field's purpose and expected content are left unspecified.

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

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

The description clearly states the resource (a business), the action (hide from clients), and gives concrete trigger examples (complaints, ownership dispute). It distinguishes this from a generic suspension by emphasizing client-facing visibility, though it does not explicitly contrast with sibling tools like owner_pause.

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 provides clear context for when to use the tool (complaints, disputes) and adds an eligibility restriction ('Only for the Awning team'). It does not explicitly mention when not to use it or name alternative tools, so it stops short of full usage 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 already indicate this is a write operation (readOnlyHint=false) and not idempotent or destructive. The description adds some context by explaining the action types (block/open/remove) and that it applies to business or staff/room, but does not disclose side effects like impact on existing bookings, cancellations, or error scenarios. With annotations covering the basic safety profile, the description provides moderate additional transparency.

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 compact three-sentence paragraph that front-loads the core purpose and key usage hints. Every sentence contributes value, and there is no unnecessary verbosity. However, it could be slightly better structured with explicit parameter explanations, but overall it is efficient.

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

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

With 7 parameters, no output schema, and very low schema coverage, the description is insufficient for an agent to correctly call the tool in all cases. It does not explain how to specify the target (whole business vs staff/room), what 'reason' is used for, the semantics of overlapping blocks, or the effect on availability. The description covers the primary use case but leaves significant 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 only 14%, so the description must compensate for undocumented parameters. It explains 'to', 'from', 'open', and 'remove_exception_id' implicitly, but does not clarify 'resource_id' (which likely identifies staff/room), 'business_id' (only partially explained in schema), or 'reason' (purpose of the block). The description does not adequately help an agent understand the full set of 7 parameters.

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

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

The description clearly states the tool's purpose: for business owners to block or open time for the whole business or a specific staff member/room, and to remove blocks. It uses specific verbs (close, open, remove) and identifies the resource scope, distinguishing it from other owner_* tools that manage schedules or bookings.

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 explicitly restricts usage to business owners signed in to Awning and explains the main scenarios (closing for day off/break/holiday, opening extra time with open=true, and removing a block with remove_exception_id). However, it does not mention alternatives or when not to use this tool, such as setting regular schedule hours versus one-off exceptions, which could be inferred but is not 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?

The destructive nature is already indicated by destructiveHint=true, and the description adds meaningful side-effect context: the client is notified and owner confirmation is required before acting. It does not contradict the annotations and gives useful behavioral guidance beyond the structured hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three short, purposeful sentences with no filler. It front-loads the key scope and action, then adds the confirmation requirement and side effect efficiently.

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 covers who can use the tool, what it does, what side effect it has, and a mandatory workflow step. It does not describe return values or failure cases, but no output schema exists and the more important safety aspects are covered by annotations.

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%, and the description does not explain booking_id or reason. The parameter names are somewhat self-explanatory, but the description provides no additional semantic meaning, constraints, or guidance beyond the raw property 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?

The description clearly states the action: "Cancels a booking on behalf of the business and notifies the client." It also specifies the actor and scope with "Only for business owners signed in to Awning," which distinguishes it from the sibling cancel_booking. The operation is specific and 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?

The description explicitly restricts usage to business owners and instructs the agent to always ask the owner to confirm first. It implies the tool is the owner-side variant of cancellation, though it does not explicitly contrast it with cancel_booking or mention edge cases like already-cancelled bookings.

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 mark the tool as destructive and readOnly=false. The description adds useful behavioral context beyond those annotations: it requires an authenticated business owner, explains that the client is notified, and clarifies when the different decision states apply. There is no contradiction with the annotations.

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 dense sentences with no filler. The audience and scope are front-loaded, the decision states are compactly enumerated, and the parentheticals efficiently attach the relevant parameter meanings. 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 mutation tool with no output schema, the description covers the essential operational context: who may call it, which decisions are available, when they apply, a precondition, and the client notification side effect. It could be even more complete by mentioning return behavior or error cases, but it is strong enough for an agent to invoke it correctly in most situations.

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. It does add meaning by linking 'reason' to decline and 'price' to quote, and it mirrors the decision enum. However, it leaves booking_id unexplained and doesn't cover constraints or required-conditional behavior for reason and price, so the 4-parameter surface is only partially documented.

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 (a pending booking) and enumerates the exact decision actions: confirm, decline, quote, complete, no_show. It also scopes the tool to business owners signed in to Awning, which separates it from customer-facing and operator tools. It doesn't explicitly name sibling alternatives, so it falls just short of full differentiation.

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

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

The description gives clear context: only for business owners signed in to Awning, and only for pending requests before the visit or for complete/no_show after the visit. It also gives a precondition: confirm with the owner before declining. It does not explicitly state when to use a sibling tool like owner_cancel_booking instead, so it earns a 4 rather than a 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?

Annotations already provide readOnlyHint=true, so the description need not restate safety. It adds valuable context beyond the annotation by describing the view granularity (day/week per resource) and the included item types (bookings, classes, blocked time, free windows). It does not cover auth failure behavior or output structure, but the read-only annotation lowers the bar.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler: the access restriction is front-loaded, followed directly by the view modes and content types. Every phrase adds either a constraint or a capability.

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 a notable gap: the description says the view is 'per staff member, room or rental pool,' but the input schema contains no parameter to select any of these resources, leaving a key part of the stated behavior uninvokable. There is also no output schema and no return-value description, so the agent cannot know what the response will contain beyond the vague content list.

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 67%: date and business_id have schema descriptions, but days does not, and the tool description adds no parameter-level meaning. The 'Day or week view' hint loosely implies days=1 vs days=7, but the description never explains how to select a staff member, room, or rental pool, despite claiming that scope in the purpose.

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

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

The description clearly states what the tool does: a read-only schedule view for business owners, showing bookings, classes, blocked time, and free windows per staff member, room, or rental pool. It distinguishes itself from siblings like owner_set_schedule (a write operation) and owner_list_bookings (booking listing only) by emphasizing the owner-only scope and the range of schedule content covered.

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 'Only for business owners signed in to Awning' gives role and authentication context, implying when this tool should be used. However, it does not explicitly contrast it with alternatives such as get_availability (for non-owners) or owner_list_bookings (for booking-only lists), leaving the decision to the agent's 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?

The description goes beyond the readOnlyHint annotation by warning that the page is third-party content and must be treated as data, not instructions, and that prices or hours must never be invented. This is valuable behavioral guidance about external content and hallucination risk.

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?

Each sentence earns its place: audience, input/output, workflow, and safety warning. The content is front-loaded with the most important scoping information and stays reasonably compact despite covering multiple aspects.

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 single-parameter read-only tool is well covered: input, output, downstream usage, and hallucination guardrails are all described. A small gap is that candidate photos are not described in terms of format or how they should be handled, but this is minor for the stated workflow.

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 no schema description coverage, the description fully compensates by explaining what the url parameter should be: the address of a page the business already owns, with concrete examples such as a website, listing, or public profile. This adds real meaning beyond the bare uri format.

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 takes a page URL and returns the page's readable text and candidate photos. This clearly differentiates it from tools like owner_setup by positioning it as the extraction step that feeds the setup call.

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 context: intended solely for business owners signed in to Awning, and placed in a workflow before a single owner_setup call. It does not explicitly name when not to use it or list alternative tools, but the ownership and workflow constraints are strong.

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?

Beyond the readOnlyHint annotation, the description discloses ordering logic (requests awaiting decision first), the default 7-day window, and that client contacts are included. This gives the agent useful behavioral expectations. It does not contradict the annotation, and it adds value without repeating it.

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 concise sentences: the first front-loads the audience restriction, the second summarizes behavior and default window. Every word earns its place with no fluff 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 read-only listing tool, the description covers audience, ordering, default window, and included contacts. However, with no output schema and only 25% parameter coverage, it leaves to/from format, status filtering, and pagination behavior unspecified. These gaps matter for reliable 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?

Schema description coverage is only 25% (only business_id has a description), so the description must compensate. It adds the default 7-day period and implies to/from define the period. However, it does not explain the status enum, date formats, or how status interacts with the ordering rule.

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 resource (booking requests) and audience (business owners), and details the output: requests awaiting decision first, then bookings in the period (default 7 days) with client contacts. The title 'Check booking requests' aligns with the behavior. It doesn't explicitly name sibling tools, so differentiation is implied 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?

The description gives a clear audience constraint ('Only for business owners signed in to Awning') and a default period, which tells you the typical context for use. However, it does not mention alternatives like my_bookings, get_booking, or owner_get_schedule, nor does it state when not to use this tool. Route selection is left partially 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 already indicate this is not read-only, is idempotent, and is not destructive. The description adds useful behavioral context beyond that: 'Existing bookings stay' and the pause is temporary, which clarifies the tool's effect on existing reservations.

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 deliver the key information with no filler. The restriction, behavior, and parameter meaning are all 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 two-parameter boolean/set operation, the description covers the essential context: who can use it, what it does, how the parameter changes behavior, and that existing bookings are unaffected. No output schema is present, so return-value details are not required.

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 description explains the meaning of the 'paused' parameter values (true stops new bookings, false resumes them), compensating for the schema's lack of a description on that parameter. 'business_id' is adequately covered by its schema description, so both parameters are semantically clear when combining schema and description.

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

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

Description states a specific action: temporarily stop taking new bookings or resume them, tied to the 'paused' boolean. It clearly identifies the tool's resource and differentiates it from cancellation by noting that existing bookings remain.

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

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

The description gives clear context by restricting use to business owners signed in to Awning, and explains the two states of use (paused=true vs paused=false). It does not explicitly name alternatives, but the scope and conditions are unambiguous enough for an agent to know when to invoke it.

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

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

Beyond the annotations, the description richly discloses behavior: use the owner's original photos by default, require owner review of edited/generated images, do not generate images or bill for generation, and only mark photos_done after successful uploads and owner confirmation. This adds critical workflow context that annotations do not convey.

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 front-loads the core purpose and then adds necessary policy constraints. It is dense and somewhat long, but nearly every sentence carries meaningful guidance; a bulleted structure would improve scannability without changing content.

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?

Despite no output schema, the description explains what a no-argument call returns ('an upload widget where supported and upload_url as a fallback') and covers failure handling, cost disclosure, owner approval, and completion criteria. An agent has enough context to invoke the tool correctly and to handle follow-up steps responsibly.

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

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

With 50% schema coverage, the description compensates well by explaining that 'files' are supported chat attachments and 'urls' are downloadable image links, and by constraining valid input ('never invent a URL or send a local file path'). It doesn't narrate draft_id and business_id, but those already have schema descriptions, so the overall parameter guidance is solid.

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 action and resource: 'Save photos for the business page' using files or urls. It also adds a clear role constraint ('Only for business owners signed in to Awning') and explains the tool can be called with nothing to receive an upload widget/fallback, which distinguishes it from generic upload tools.

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 explicitly says when to use the tool (owner photo uploads), when to use the fallback ('If attachments cannot be transferred, return the upload link'), and when to use other assistant tools ('Editing or image generation is optional...use the assistant's own image tools'). It also gives clear prohibitions: never invent a URL or send a local file path.

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 signals a safe read, and the description reinforces this with 'Shows.' It adds valuable context beyond annotations by disclosing the auth requirement ('Only for business owners signed in to Awning') and clarifying it covers both draft and existing business states, plus submission blockers.

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 deliver the audience restriction and the core behavior without any filler. Every phrase earns its place, and the most important scoping information is front-loaded.

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 low-complexity, read-only tool with one optional parameter and no output schema, this description is complete: it identifies the intended caller, the object being previewed, the two possible states, and the kind of information returned (client view and submission blockers).

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 optional parameter is already well documented with 'Only needed if you manage several businesses.' The tool description does not add further parameter-level meaning, so the schema carries the semantic weight and the baseline score applies.

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

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

The description states a specific verb and resource: 'Shows how clients will see the business' and adds precise scope ('draft or existing') and an extra distinguishing behavior ('what blocks submission'). This makes it clear this is a client-facing preview tool, not a status or edit tool.

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

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

The description gives a clear contextual boundary: 'Only for business owners signed in to Awning.' It implies when the tool is useful—when an owner needs to preview the client view or understand submission blockers—but it does not explicitly name sibling alternatives or say when not to use it.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=true, so the description is not required to restate those. It adds valuable context by stating that existing bookings are kept, which clarifies the destructive scope and reassures that the operation does not cascade to bookings. It also notes the business-owner auth requirement, which is useful behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. The audience restriction, core action, and key side-effect are all front-loaded and each 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 3-parameter tool with no output schema, the description covers the essential context: who can use it, what it replaces, and that bookings are preserved. It does not mention whether the operation is reversible or what the response looks like, but the annotations already cover idempotency and destructiveness, so the remaining gaps 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 only 33%, so the description carries some burden. It explains that resource_id selects a staff member/room and business_id is only needed for multi-business management, which adds meaning beyond the bare schema. However, it does not explain the hours array format or the open/close time format, leaving the agent to rely on the schema's sparse descriptions.

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 ('Replace weekly hours') and resource ('business, or one staff member/room with resource_id'), and clearly distinguishes from siblings like owner_get_schedule. It also names the intended audience ('Only for business owners signed in to Awning'), which helps an agent select it over customer-facing tools.

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 explicitly says it is only for business owners signed in to Awning, and clarifies that it replaces weekly hours rather than merging or adding. It does not explicitly name alternatives like owner_get_schedule or owner_block_time, but the scope restriction and replace semantics give clear context for when to use it.

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

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

Beyond the annotations (mutating, idempotent, non-destructive), the description discloses the iterative clarification protocol: do not invent missing details, ask about ambiguous days/times/timezone, batch open_questions into one message, repeat until ready_to_submit, and delegate image saving to owner_photos. It also explains what the response contains, which is especially valuable given there is no output schema.

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?

Roughly 150 words cover a genuinely complex multi-turn workflow with no filler; the most important constraints (don't invent, keep draft_id, batch questions, loop until ready_to_submit) are front-loaded. Every sentence contributes either a prerequisite, a mode switch, or an orchestration rule.

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 4-parameter tool with no output schema, the description supplies the missing workflow context: response shape (accepted, missing, open_questions), iteration until ready_to_submit, the preview/approval gate, and image-handling delegation to owner_photos. An agent has enough to begin and continue the guided setup 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?

With only 50% schema coverage, the description adds important meaning to draft_id, new_business, and copy_from_business_id, including the distinction between a new business and a new location of an existing business. It does not enumerate the large answers object, but the schema provides field-level detail and the description explains the conversion rule and the break-hour nuance.

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

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

The description identifies a specific action (guided business onboarding for Awning owners), a specific resource (a business draft), and the key behavior (converting natural-language description, prices and hours into structured answers). It also distinguishes itself from related sibling tools like owner_preview, owner_submit, and owner_photos, so an agent can tell this tool apart.

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 explicit conditions and routing: only for business owners signed in to Awning, use new_business=true for a separate business, and use copy_from_business_id and ask only what differs for a new location. It also says to use owner_preview and explicit approval before owner_submit, which is clear when-to-use guidance rather than leaving alternatives 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?

The annotations already declare readOnlyHint=true, and the description's 'Status of...' wording is consistent with a read-only operation, so there is no contradiction. The description adds useful context that only signed-in business owners can use it and lists the status contents. However, it does not disclose response shape, what happens without business_id, or how pending requests are defined.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with no filler, and the eligibility qualifier is front-loaded. Every phrase contributes either scope or content information. It is concise, though the second sentence is a noun-phrase list rather than a crisp verb-led statement.

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 status tool with one optional parameter and no output schema, the description covers the key data categories and the owner-only restriction. It does not explain exact return formatting or edge cases like multiple businesses, but the schema covers the parameter and the annotations cover the safety profile. This is adequate but not exhaustive.

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%: the only parameter, business_id, is documented as 'Only needed if you manage several businesses.' The tool description itself adds no parameter-level detail, so it stays at the baseline 3 for fully schema-covered parameters.

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

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

The description clearly states that the tool surfaces the status of a signed-in business owner's businesses and applications, including pending requests count and unfinished draft. It is easy to identify as a read-only status/dashboard tool. However, it lacks an explicit verb like 'Gets' or 'Returns,' and it does not distinguish itself from related siblings such as op_businesses or op_applications.

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

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

The only usage guidance is the eligibility qualifier 'Only for business owners signed in to Awning,' which implies non-owners should not use it. It does not explain when to prefer this tool over related owner tools or what scenario would route an agent here. This is implied context rather than explicit alternative selection 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 already cover read-only/mutation, idempotency, and destructiveness. The description adds useful behavioral context beyond that: it states an authorization prerequisite ('Only for business owners signed in to Awning') and a social/safety requirement ('Confirm with the owner first'). No contradiction with annotations.

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, each earning its place: audience constraint, main action, and a required confirmation step. The key information 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?

For a two-parameter submit action, the description covers who, when, what, and a required precondition. It does not explain return values or post-submission behavior, but with no output schema and straightforward semantics, this is a minor gap rather than a blocker.

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 describes business_id well, and the description's phrase 'finished onboarding' hints at what draft_id refers to, but there is no explicit mapping or explanation of draft_id. With 50% schema coverage and no parameter details in the description, the meaning is adequate but not fully clarified.

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

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

The description names a specific verb ('Submits') and a clear resource ('the finished onboarding (or a corrected business after rejection)') for review. This clearly distinguishes the action from editing or setup operations, and the title reinforces the same intent.

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

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

The description gives clear conditions: only for signed-in business owners, only after onboarding is finished or after a rejection correction, and only after confirming with the owner. It does not explicitly name alternatives or say when not to use it, but the context is strong enough for an agent to route correctly.

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 cover write semantics, idempotency, and non-destructiveness; the description adds the authorization context and enumerates the mutable fields. It does not disclose whether the update is partial or full replacement, nor what the response contains, so it adds only modest behavioral context beyond annotations.

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 with no filler: the access restriction comes first, then the action and the list of changeable fields. Every phrase 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 7 optional params, a nested contacts object, and no output schema, the description plus schema is workable but leaves update semantics and return behavior unspecified. The annotations partly fill the safety profile, but an agent still has to infer partial-update behavior and what the tool returns.

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 only 14%, and the description compensates by mapping plain-language terms to several params: 'public contacts' to contacts, 'automatic confirmation' to auto_confirm, and 'cancellation rules' to late_fee_pct/free_cancel_hours. However, the 'cancellation rules' grouping is ambiguous and business_id is omitted from the description (though the schema documents it).

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 uses a clear verb ('Change') and identifies the resource (business details) plus the specific fields affected: name, description, public contacts, cancellation rules, automatic confirmation. It does not explicitly differentiate from sibling owner_update_offering, so it stops 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?

It gives a clear precondition ('Only for business owners signed in to Awning') and implies the use case (updating business details), but it never states when not to use it or names alternatives such as owner_update_offering. Usage is inferable 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 indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds an authentication requirement and mentions archiving, which is useful context, but it does not disclose more nuanced behavior such as partial-update semantics or archive reversibility.

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 that front-loads the auth constraint and then lists the editable fields. Every phrase earns its place, and there is no redundant 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?

This is a 9-parameter mutation tool with no output schema and minimal schema descriptions. The description gives only a high-level field list and does not explain required parameters, units, business_id conditions, or expected behavior on archive, leaving an agent under-informed.

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 schema description coverage at only 11%, the description carries the burden of explaining parameters. It maps plain-language terms like 'advance booking' and 'cleanup time' to fields such as min_advance_hours and buffer_after_min, but it leaves units, the required offering_id, and the conditional business_id 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?

The description clearly states the operation ('Change') and the resource (service, class, or rental) with a concrete field list. It is not a tautology, but it does not explicitly differentiate from sibling tools like owner_update_business.

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 provides a clear usage condition: 'Only for business owners signed in to Awning.' However, it does not state when to use this tool versus alternatives, nor does it mention exclusions or related 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?

The annotations declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds a crucial behavioral trait: the side-effect of generating future classes for the booking horizon, which is not implied by the annotations. It also notes that it is only for business owners, which is an authorization requirement not in the annotations. This adds value beyond the annotations, covering a key behavioral consequence that an agent should know before invoking.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, concise, and front-loaded with the key constraint ('Only for business owners...') and the main action ('Set when a class runs'). The second sentence adds the important side-effect. There is no waste, and it earns its place. It could be slightly more structured, but it's efficient.

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

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

Given the tool's moderate complexity (3 parameters, nested schedule array), the description is short. It does not explain the schedule parameter's structure or how future classes are generated in detail, nor does it mention return values (though no output schema exists). However, the schema provides some structure, and the annotations cover idempotency and safety. For an agent to correctly construct the schedule array, it might need more info on 'days' and 'time' formats, but the schema gives examples. Overall, it's adequate but missing some detail on the schedule parameter and the generation 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?

The schema description coverage is 33%, meaning only one parameter (business_id) has a description, while schedule and offering_id lack them. The description does not add any parameter-specific meaning, but the schema provides some hints for schedule (e.g., 'days' example) and business_id has a description. The description mentions the purpose but not the parameters' role. Since coverage is low, the description could compensate, but it doesn't. Baseline 3 is appropriate because the schema covers some parameters and the description gives context but not parameter details.

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

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

The description clearly states a specific action ('Set when a class runs') on a specific resource ('sessions' implied by the name, but contextually 'class timetable'), and explains a key side-effect: 'future classes are generated for the booking horizon.' This distinguishes it from sibling tools like owner_set_schedule, which likely manages the schedule differently, and from booking tools. The verb 'upsert' is implicit in the name, but the description makes the purpose clear.

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

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

The description gives a clear context for when to use it: 'Only for business owners signed in to Awning.' This implies it's for owners as opposed to customers, aligning with the 'owner_' prefix in siblings. It does not explicitly state when NOT to use it or name alternatives, but the ownership restriction and the action of setting class times are sufficient for an agent to select it over booking or availability tools. There is no explicit exclusion, but the context is clear enough.

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 read-only behavior, so the description does not need to repeat safety guarantees. It adds value by disclosing the return shape ('cards with business_id, offerings and page_url') and the filtering modes, giving the agent a concrete sense of what the call produces.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler: the first states purpose and scope, the second states filters and return fields. The category list is long but informative, and the most important behavioral fact (returns cards) is placed near the end without bloating the description.

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 search tool with no required parameters and no output schema, the description covers purpose, main filter options, and result fields. It does not describe pagination or the relationship between coordinates and radius, but those are minor given self-explanatory parameter names and schema constraints.

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 43%, so the description carries some burden. It adds meaning by mapping filter dimensions to categories of parameters ('text', 'city/country or coordinates', 'category'), but it does not clarify limit or radius_km, and those parameters lack schema descriptions; the compensation is 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?

The description uses a specific verb ('Find') and a clear resource ('local businesses that take bookings'), enumerating relevant categories and filter dimensions. It does not explicitly name or differentiate from sibling tools like get_business, but the search-focused scope is clear from the return-card language.

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 when to use the tool: when the agent needs to discover local bookable businesses by text, location, or category. However, it provides no explicit guidance on alternatives or exclusions, such as using get_business for a single business's details.

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