concierge

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine, non-redundant behavior: the call yields no file in this build, which saves the agent from treating an empty result as a successful download. It stops short of saying whether the call errors or returns an empty payload.

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 filler; the capability statement comes first and the build caveat second, which is the right order.

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, annotated, no-output-schema tool, the definition covers what the agent needs to know about this tool's own behavior. What is missing is the surrounding context an agent actually needs when a tool is stubbed out: which sibling to call instead for invoice content.

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

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

Schema description coverage is 100% and the schema itself states the invoiceId is "Ignored until phase 2," so the description adds nothing beyond it. Baseline 3 applies where the schema does the heavy lifting for a single required parameter.

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

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

The description names a specific verb and resource ("Returns an invoice PDF") and immediately qualifies it with the build limitation. It does not differentiate from the most confusable sibling, get_invoice, which likely exposes the same invoice data in a different form, so an agent still has to infer the distinction.

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 strong when-not-to-use signal ("Not available until phase 2, and this build returns no file"), which is more exclusion guidance than most definitions offer. However, it does not route the agent to an alternative such as get_invoice or list_invoices, so the agent is left without a next step in this build.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered. The description's one genuine addition is "public", signalling no authorization is required, but it says nothing about caching/staleness or whether the card can change over time.

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 the resource stated first and the returned fields enumerated after. There is no filler, hedging, or repeated 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?

The tool is trivially simple: no parameters, a published output schema, and complete annotations, so the description only needed to name the resource and its fields, which it does. Only the absence of any tie-breaker against whoami keeps it short of full marks.

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

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

The tool takes zero parameters, so the baseline is 4 per the rubric; the schema has nothing to misunderstand. Nothing in the description suggests optional selectors or filtering that would mislead an agent.

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?

"Returns the public EAC Partners business card" pairs a specific verb with a specific resource, and the field list (name, emails, phone, address, time zone, website) makes the payload unambiguous. It does not differentiate from near-siblings such as whoami, which an agent may reasonably confuse with contact-card retrieval.

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

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

Usage is only implied by the content: an agent infers this is the tool for contact/support details. There is no explicit when-to-use statement and no guidance on choosing it over whoami, which is the one sibling with plausible overlap.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral information — that the payload is trimmed to summary and URL unless full text is enabled — but never says how full text is enabled, leaving the agent unable to act on that condition.

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

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

Two sentences, zero filler. The primary behavior and the addressing modes come first, and the payload caveat follows, which is the right ordering for an agent scanning the definition.

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

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

An output schema exists, so return structure need not be explained, and the description is adequate for a simple single-record getter. The gaps are the dangling 'full text is enabled' condition with no way to trigger it and the unaddressed case where all optional parameters are omitted.

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

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

Schema description coverage is 100%, so the schema already explains that url is an alternative to verticalSlug+slug and that slug and verticalSlug are required together. The description restates the same either/or addressing scheme without adding format, precedence, or error-behavior detail. Baseline 3 applies.

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

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

States a specific verb and resource: 'Returns one Insights article', with the lookup keys named. The singular 'one' implicitly distinguishes it from list_insights and search_insights, but it never names those siblings explicitly, so the differentiation is 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 description presents the two addressing modes (vertical+slug or canonical URL), which is useful usage context. However, it gives no guidance on when to prefer this over list_insights or search_insights, and says nothing about what happens when no parameters are supplied even though all three are optional.

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 readOnly/idempotent annotations, the description discloses the critical behavior that this build returns no record, which saves the agent from wasted calls and misinterpreted empty results. It does not explain error shape or whether the call succeeds silently versus failing.

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

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

Two short sentences, front-loaded with what the tool does and immediately followed by the constraint. Every clause carries information; nothing is redundant.

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

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

For a single-parameter stub with no output schema, the description covers the essentials: what it would return and why it currently returns nothing. It falls short only in not routing the agent to a working alternative.

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

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

Schema coverage is 100% and the invoiceId property already documents that it is "Ignored until phase 2." The description adds no further meaning about the parameter, so the baseline 3 applies.

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

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

"Returns one invoice" gives a specific verb and resource, which contrasts implicitly with the sibling list_invoices. It does not name that sibling or state the single-record scope explicitly, so differentiation is left to inference.

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

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

The description does state a clear exclusion ("Not available until phase 2"), which effectively tells the agent not to rely on this tool. However, it never points to the alternative (list_invoices) or explains how to obtain invoice data in the current build.

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 read-only, idempotent, non-destructive, closed-world behavior, so safety is covered. The added sentence about host AI vendors seeing tool calls and results is genuinely useful contextual disclosure beyond annotations, but it is peripheral to how the tool itself behaves, and the return shape is covered by the 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?

Two short sentences, front-loaded with the purpose, with no filler. The second sentence sits slightly awkwardly next to the purpose statement but is brief and adds distinct 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?

With no parameters, rich annotations, and an output schema documenting the return value, the description supplies everything an agent needs to select and call the tool. The only missing piece is explicit invocation guidance, which is minor given the tool's simplicity and singularity.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline for zero-param tools applies. Nothing in the description is needed to clarify inputs.

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 ("Returns the Concierge privacy notice") that unambiguously identifies the tool. No sibling covers privacy notices, so differentiation is achieved implicitly by the unique subject matter rather than by explicit contrast.

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

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

Usage is only implied: an agent can infer the tool is for retrieving the privacy policy, but the description never states when to call it (e.g., on user request, before handling data) or when another tool would be more appropriate. No alternatives are named, though none of the siblings overlap meaningfully.

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 this is a non-readonly, non-destructive, non-idempotent, closed-world write. The description adds two things beyond that: the submission is queued (implying asynchronous handling, not immediate processing) and web addresses are rejected as a validation rule. It does not say who sees the note, whether duplicates are possible given the non-idempotent hint, or what happens after queueing.

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 filler, front-loading what the tool does and immediately following with the one hard constraint. Nothing is redundant or buried.

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

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

An output schema exists so return values need no explanation, and parameters are fully covered by the schema. However, for a queueing write tool the definition leaves the post-submission behavior and the reason for the web-address rejection unstated, which is a meaningful gap for an agent deciding whether to retry or how to phrase the call.

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

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

With 100% schema description coverage the schema already documents all four parameters, so the baseline is 3. The description reinforces the note constraint ("short", no web address) but adds no format, length, or validation detail beyond what the schema's note field already states.

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

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

"Queues a short note from a prospective customer" gives a specific verb (queues) and resource (lead note), and the phrase "prospective customer" distinguishes it from siblings like open_support_request or submit_referral. It does not explicitly name an alternative, but the action 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 mention of "a prospective customer" implies the sales/lead context in which this should be used, but there is no explicit when-to-use vs when-not guidance and no named alternative among the sibling tools. The agent must infer the boundary against open_support_request and submit_referral.

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 this a safe, idempotent, closed-world read, so the safety profile is covered. The description adds a genuinely important behavioral fact beyond the annotations: the call is a stub that returns zero records in this build, which prevents the agent from mistaking an empty result for "no billed time exists."

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

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

Two short sentences, zero filler. The purpose comes first and the availability caveat follows immediately, so an agent reading only the opening words still gets the right signal.

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 parameterless stub with no output schema, the description covers everything an agent needs: what it nominally does and the fact that it yields nothing today. The only gap is lack of a pointer to whichever tool actually supplies billed time.

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 zero parameters and full schema coverage there is nothing to disambiguate, so the baseline of 4 applies. The description correctly implies no filtering is possible by advertising no scoping inputs.

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?

"Lists billed time" gives a specific verb plus resource, and no sibling tool covers billed time, so the agent can place it in the catalog without ambiguity. It stops short of distinguishing itself from nearby list_* tools (list_invoices, list_subscriptions) by scope, but the resource is distinct enough to be actionable.

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 tells the agent when NOT to use it: "Not available until phase 2, and this build returns no records." That is a clear, decisive usage constraint rather than implied guidance. It does not point at an alternative tool for getting billed time today, which is the only missing piece.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is fully covered. The description adds one genuinely useful behavioral fact — that article bodies are not returned — but otherwise restates the return fields, which the output schema already carries.

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 filler; the result contents come first and the key limitation is stated second so it is not buried.

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?

Because an output schema exists, the description does not need to enumerate return fields, and the argument list is fully documented in the schema. The remaining gaps are the unmentioned 'vertical' filter and the unstated relationship to search_insights and get_insight for a tool with three closely related siblings.

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

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

There is a single optional parameter, 'vertical', and schema description coverage is 100%, so the baseline is 3. The description never mentions filtering by vertical at all, so it adds no meaning beyond the schema.

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

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

States a specific verb and resource ("Lists Insights articles") and names the fields returned, plus the significant exclusion that full article text is not included. This implicitly separates it from get_insight, though it never names the sibling explicitly.

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

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

The note that full article text is absent implies this tool is for browsing/metadata rather than reading, hinting at get_insight as the alternative. There is no explicit when-to-use guidance and no mention of how it differs from search_insights, which is the closest sibling.

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 the operation as read-only, idempotent, and non-destructive, so the safety profile is already covered. The description adds behavior that the annotations cannot express: this build returns no records and is gated behind phase 2, which prevents wasted calls and explains an empty result. It stops short of saying whether a future build will accept filters or pagination.

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 clauses, both of which earn their place: one identifies the resource and the other states the availability constraint up front. There is no filler, no repetition of the schema, and no hedging.

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 no-argument stub with no output schema, the description covers the essentials: what the tool will do and why it currently yields nothing. It does not say what fields an invoice record will eventually contain or when phase 2 lands, though both are moot while the tool is inert.

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 are zero input parameters, so there is no parameter meaning to document; the empty schema is fully self-describing. This dimension is a baseline case rather than a strength of the 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 states a specific verb and resource ('Lists customer invoices'), which is clear enough to distinguish it from unrelated siblings like whoami or request_appointment. However, it does not differentiate itself from the closely related get_invoice, list_billed_time, or list_subscriptions, so an agent must infer the distinction from the names alone.

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

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

The description gives a strong negative signal, that this tool is unavailable and returns no records, which effectively tells the agent not to call it. It never names an alternative for retrieving a single invoice (get_invoice) or points the agent anywhere else, so the guidance is only half complete.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds no behavioral context of its own — nothing about pagination, volume of results, or what an "offering" record contains. The "ERP title comes from configuration" line is opaque and gives the agent no actionable information.

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?

Only two sentences, but the second is unexplained noise and the first buries the core purpose behind an awkward "footnote of small demonstrations" clause. Front-loading is weak and the wording would need trimming rather than expanding.

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

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

An output schema exists, so return values need not be described, and annotations cover safety. Still, the definition leaves the central concept (what an "offering" is) and the filter's effect undefined, which is not enough for an agent to decide reliably whether to call it.

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

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

With a single optional parameter at 100% schema description coverage, the schema already documents the category filter, so the baseline of 3 applies. The description never mentions the category parameter or what values it accepts, so it contributes nothing beyond the schema.

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

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

The verb+resource ("Lists EAC Partners offerings") is identifiable, but "offerings" is never defined and the qualifier "including a footnote of small demonstrations built by EAC Partners" muddies rather than sharpens scope. The closing sentence ("The ERP title comes from configuration") describes an unrelated implementation detail. No sibling tool covers offerings, so differentiation is implicit at best.

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

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

There is no statement of when to call this tool, when not to, or which sibling (e.g. match_need, list_subscriptions) to prefer for adjacent needs. The only usable cue is the optional category filter, which is implied rather than explained.

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 this a safe, idempotent, closed-world read. The description adds two pieces of real value: results are constrained to a specific timezone, and 'Phase 1 uses a deterministic schedule stub' warns that returned availability is synthetic, not live — a trait no annotation conveys. The dev-facing 'Phase 1' phrasing slightly weakens 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 short sentences with zero padding, leading with what is listed and the timezone constraint before the caveat. Every clause carries information.

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

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

All three parameters are documented in the schema and an output schema exists, so the description only needs to orient the agent — which it does, resolving the timezone question and flagging the stub data. Only the missing hand-off to request_appointment keeps it from a 5.

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

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

Schema coverage is 100%, so days, from, and meetingType are already fully documented, including the 1-21 range and default. The description adds only the fixed timezone, which is useful context but not parameter-level meaning beyond the schema.

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

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

States a specific verb and resource ('Lists open appointment slots') plus scope details: timezone America/New_York and the three supported meeting types. It doesn't explicitly name request_appointment as the booking counterpart, but the purpose is unmistakable and readably distinct from the other siblings.

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

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

Implies the discovery use case by enumerating valid meeting types, but never states when to call this versus request_appointment, nor that list_open_slots is the prerequisite step before booking. 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 declare read-only, idempotent and non-destructive behavior, so the safety profile is covered. The description adds genuinely non-obvious operational context that annotations cannot express: the tool is a phase-2 stub and will yield an empty result. It does not say whether that manifests as an empty array or an error, which is the remaining gap.

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

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

Two short sentences with the purpose front-loaded and the availability caveat immediately after. No filler or redundancy; every sentence carries information an agent needs.

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 no-argument list tool with full annotation coverage and no output schema, the description supplies what matters most: that the call is currently a no-op. It could be slightly more complete by stating the expected response shape (empty list versus an error), but nothing essential 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 tool takes zero parameters, so there is no parameter semantics for the description to carry; the baseline for a parameterless tool applies. Nothing in the description is needed to clarify calling conventions.

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 ("Lists subscriptions"), which is unambiguous about what the tool does. It does not explicitly contrast itself with the many other list_* siblings, but the resource noun is distinct enough that confusion is unlikely.

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 strong, explicit when-not-to-use signal: the tool is unavailable until phase 2 and returns no records in this build, which effectively tells an agent to avoid calling it. It stops short of naming an alternative route for obtaining subscription data.

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, idempotent, closed-world and non-destructive, so the bar is lower. The description nonetheless adds a real trust guarantee beyond them: results are grounded strictly in the published catalog and the tool "does not invent services," which tells the agent output may legitimately be empty rather than fabricated.

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, zero filler, with the core action front-loaded and the constraint following it. Every sentence carries distinct 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?

An output schema exists and annotations are rich, so return format and safety need no explanation. However, for a matching tool it omits what happens when nothing in the catalog fits and how to phrase the need for best results, leaving a modest gap.

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

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

With one parameter at 100% schema coverage, the schema already defines `need` as 1–500 characters. The description only adds that the need should be "short" and that it is a need rather than a query string; it does not clarify whether keywords or a full natural-language sentence works better.

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

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

States a specific verb and resource ("Matches a short need to offerings") plus a scope qualifier ("published catalog only"). It is clearly distinct from list_offerings, though it never names that sibling explicitly.

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

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

Implies the use case (caller has a free-text need and wants a catalog match) but gives no explicit when-to-use/when-not guidance or naming of alternatives such as list_offerings. The agent must infer that this is the semantic-search entry point versus browsing the catalog.

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?

This is the definition's strongest contribution: it discloses that the current build does not store a request, so the agent knows the call is effectively a no-op despite the mutation-shaped annotations (readOnlyHint=false, idempotentHint=false). A detailed note on what the call returns instead, an error or a silent success, would close the remaining gap and a return value has no output schema to cover 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 short sentences with no filler, and the availability blocker is stated immediately after the purpose. Every clause earns its place in a stub definition like this.

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

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

For a single-parameter stub, the description covers purpose and the crucial unavailability fact, which is what an agent most needs. The only missing piece is the runtime behavior of a call made anyway, an error versus a silent success, which matters because there is no output schema to explain 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 coverage is 100% and the single parameter's own description already says it is ignored until phase 2, so the tool description adds nothing beyond what the schema provides. Baseline 3 applies when the schema carries the parameter meaning.

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?

"Opens a support request" gives a specific verb and resource that an agent can distinguish from siblings like request_appointment or submit_referral. It stops short of naming any alternative for users who need support today, so it is clear but not fully differentiated.

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 states the tool is not available until phase 2, which is a strong when-NOT-to-use signal and effectively prevents wasted calls. It does not point to any sibling or workaround for handling support needs in the current build, so the alternative path is left to inference.

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

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

Beyond the annotations, it discloses that the operation only queues a request, that its status is pending confirmation, and that nothing is sent or held automatically. These details clearly define the practical effect and prevent an agent from promising a reserved slot or completed notification.

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

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

Three short sentences front-load the action and prerequisite, then state the resulting status and important non-effects. Every sentence contributes useful selection or invocation information without repetition.

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

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

Together with the fully described flat input schema, output schema, and annotations, the description supplies the essential workflow, effect, and status context needed for correct invocation. No material prerequisite or behavioral limitation is left ambiguous.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters, including the slotId source and meetingType constraint. The description reinforces the slotId workflow but adds no substantive parameter meaning beyond those schema 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?

“Queues an appointment request” gives a specific verb and resource, while the slotId prerequisite connects it to the list_open_slots workflow. It also distinguishes requesting an appointment from merely listing availability or obtaining a confirmed 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 description explicitly says to use a slotId previously returned by list_open_slots, establishing when the tool enters the workflow. The pending-confirmation and no-automatic-hold statements further prevent the agent from using or representing it as an instant booking tool.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds that results carry a summary and canonical URL, but says nothing about result ordering, relevance ranking, total-hit counts, or what happens when nothing matches. With annotations carrying the behavioral burden, this is adequate but thin.

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, front-loaded sentences with no filler; the purpose comes first and the return shape second. The return sentence is largely redundant given an output schema exists, which keeps it from a 5.

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, fully documented read tool with an output schema, the description covers what it searches and what it returns. The only real omission is explicit routing against get_insight and list_insights, which matters given a crowded sibling set but is not fatal.

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%, with both query (1-200 chars) and limit (1-20, default 5) fully documented in the schema. The description adds no extra meaning such as matching semantics, case sensitivity, or whether the query supports multiple terms. Baseline 3 applies when the schema does all the work.

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

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

States a specific verb+resource ('Searches Insights titles and summaries') and its search scope. It is distinguishable from get_insight (single fetch) and list_insights (browse) by implication, but it never names those siblings, so the differentiation is left to the agent's inference.

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

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

The phrase 'searches titles and summaries' implies keyword-driven lookup rather than enumeration, which hints at when to prefer this over list_insights. However, there is no explicit when-to-use or when-not-to-use statement, and no guidance on when to fall back to get_insight for full content.

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, it discloses the key operational behavior: the referral is queued for human review rather than processed through automatic sending. This prevents the agent from implying that a referral, notification, or prospect contact has already been transmitted.

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

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

Two short sentences front-load the action and then state the most important behavioral caveat. There is no redundant or speculative 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 flat-input submission tool, the description supplies the workflow and delivery expectations needed to invoke it responsibly. The fully documented input schema, annotations, and presence of an output schema cover the remaining structural details.

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

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

Schema description coverage is 100%, so the structured fields already explain all six parameters, including optional prospect details and the notes restriction. The description adds no further parameter-level meaning, making the baseline score appropriate.

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

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

The description gives a specific action, resource, and outcome: queuing a partner referral for staff review. It does not explicitly distinguish this workflow from siblings such as leave_lead_note or open_support_request.

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 partner-referral and staff-review context makes the intended use case clear, while 'Nothing is sent automatically' warns against using it with an expectation of immediate outreach. It stops short of naming conditions or alternatives for choosing this tool over another request or note 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 establish read-only, idempotent, closed-world behavior, so the description's extra burden is low. It earns credit for disclosing a non-obvious runtime trait — that sign-in is not enabled and the call yields no customer record — which an agent could not learn from the annotations or empty 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?

Two short sentences, front-loaded with the nominal purpose followed by the caveat. Slight overlap between "sign-in is not enabled" and "returns no customer record," but both carry distinct 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 zero-parameter, closed-world read with no output schema, the description covers what the agent needs: what it nominally does and that it will not return data in this build. It does not specify the shape of the (empty) response, but that is a minor gap given the tool's simplicity.

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

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

The tool takes zero parameters and schema coverage is 100%, so the baseline is 4. The description correctly adds nothing about parameters because there is nothing to configure.

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?

"Reports the signed-in customer" gives a specific verb and resource, and the second sentence immediately scopes the expectation: this build returns no record. No sibling in the list covers the same concept, so there is nothing to differentiate against, which is the only reason it falls short of a 5.

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

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

There is no explicit when-to-use or alternative named, but the caveat that sign-in is disabled and no customer record is returned effectively signals the agent should not depend on this call for identity. The guidance is implied through the limitation rather than stated as usage policy.

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