Twelfth

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

Annotations already declare readOnly, idempotent, closed-world, non-destructive, but the description adds genuinely non-derivable interpretive context: only the two most recent snapshots are compared, missing lines reflect file completeness, and sparse snapshots cannot prove duration or discontinuation. That caveat meaningfully shapes how an agent should present results.

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

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

Three sentences, all load-bearing: scope first, then triggers, then the interpretive caveat. No filler and nothing important buried at the end.

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 explained, and the description covers scope, triggers, and result interpretation. It is essentially complete for a two-parameter read tool, with only the absence of an explicit when-not-to-use note as a minor gap.

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

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

Schema description coverage is 100%, so both parameters (supplier_name, limit) are fully documented in the schema and the description need not restate them. It adds no extra syntax or format detail, so the baseline 3 applies.

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

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

States a precise verb (compare), resource (supplier offers), and scope (latest two saved offers within the user's workspace remit). No sibling tool performs historical offer comparison, so the agent can select this without confusion.

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

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

Gives explicit trigger scenarios — 'what changed', restock, cost, availability, ETA, terms questions — which is clear when-to-use guidance. It does not name an alternative tool or a when-not-to-use condition, so it stops short of 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 declare readOnlyHint, idempotentHint, non-destructive, and openWorldHint=false, so the safety profile is covered. The description's only added signal is the word 'visible', hinting at permission-scoped results, but it does not explain what visibility means, what happens if the entity is unknown, or result limits.

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 core purpose and no wasted preamble. Minor redundancy between 'similar products' in the title and 'alternatives or comparable products' in the body 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?

With an output schema present, return values need not be explained, and annotations cover the safety profile for this simple single-parameter read tool. The remaining gap is the undefined scope of 'visible' and no sense of result breadth, but nothing essential to invoking it correctly is missing.

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

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

Schema description coverage is 100% and the single parameter is fully documented ('Entity name exactly as the user wrote it'), so the baseline of 3 applies. The description adds nothing about the parameter beyond what the schema 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?

States a specific verb ('Find') and resource ('visible alternatives or comparable products in the same category'), which is concrete enough to distinguish it from catalogue search or listing tools. However, it does not name a sibling tool it could be confused with, so it stops 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?

'Use for substitutes, alternatives, or similar items' restates the purpose as usage guidance rather than giving conditions, prerequisites, or when-not-to-use advice. No alternative tool (e.g. search_catalogue, get_product_master) is named for the case where the agent wants exact matches or broader search.

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 and destructiveHint=false, so safety behavior is covered. The description adds useful context about what is returned (catalogue-product and open-recommendation counts) and that ranking is optional, but does not describe result limits or ordering defaults beyond what the schema states.

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

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

Two tight sentences, front-loaded with the matching behavior and followed by the return/ranking information. No filler or redundancy.

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

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

With a full output schema, complete parameter descriptions and annotations, the description only needs to convey the matching model and output shape, which it does. It is nearly complete, missing only explicit guidance on alternatives for supplier lookups.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema. The description only echoes the ranking concept ('optional ranking by either count') without adding format, default, or edge-case detail beyond the schema.

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

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

The description gives a specific verb (matches) and resource (suppliers) plus the matching modes (name, fragment, acronym) and the returned payload. It is clearly distinguishable from sibling tools like get_supplier_constraints or compare_supplier_offer_history, though it never names them 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?

Usage is implied by the description ('matches a supplier name, fragment or acronym') and the schema note that omitting query lists everything, but there is no explicit when-to-use vs. when-not or pointer to an alternative sibling for supplier lookup.

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 a closed-world scope, so the safety profile is fully covered elsewhere. The description adds only the "visible" qualifier, hinting at permission-filtered results — useful but thin given how little it explains about what is returned.

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 scope constraint placed immediately after the purpose. 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?

An output schema exists, so return values need not be described, and both parameters are fully covered by the schema. For a low-complexity, two-optional-parameter read tool this is nearly sufficient; only sibling differentiation within a 27-tool family is missing.

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

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

Schema description coverage is 100%, so both parameters (category and entity_name) are already documented in the schema with clear semantics. The description adds nothing about parameter behavior or the relationship between the two filters, 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?

The description states a concrete verb ("Read") and resource ("visible competitor and matched-line fields"), which is more specific than the title alone. It does not, however, name a sibling or explain how it differs from tools like find_similar_products or compare_supplier_offer_history.

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

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

"Use only for competitor-pricing questions" gives a clear when-to-use condition with an implicit exclusion of other question types. It stops short of naming an alternative tool for those other cases, so routing for adjacent tasks 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds one genuinely non-redundant behavioral boundary, the temporal scope ('current' only, 'does not read past decisions'), but says nothing about staleness, refresh, or scoping failures. Useful but thin added context.

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

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

Two short sentences, the affirmative scope front-loaded and the negative scope immediately after. No filler, no repetition of the title or name.

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

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

An output schema exists, so return-value structure need not be described, and annotations cover the safety profile. For a two-parameter read-only tool the description is essentially complete; only the ambiguity against get_entity_profile 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?

Schema description coverage is 100%, so both parameters (entity_name and the entity_type enum) are already fully documented, including the 'omit to match either' behavior. The description only echoes 'a named product or supplier' and adds no syntax or matching semantics beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb ('Reads') and a concrete set of resources ('recommendation rationale, evidence, rule meaning and provenance') scoped to a named product or supplier. An agent can tell it retrieves context rather than raw master data. However, it does not differentiate itself from the nearby sibling get_entity_profile, which an agent could easily confuse it with.

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 resource description; the one explicit constraint is the exclusion 'It does not read past decisions.' No positive when-to-use guidance and no named alternative (e.g. a history or decisions tool) is offered, so the agent must infer selection from context.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior. The description adds meaningful context beyond that: results are limited to 'visible' rows and are bound to the current work-unit snapshot, which tells the agent about permission-scoped and snapshot-pinned data.

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

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

A single front-loaded sentence with the verb and resource scope up front and no filler. Efficient, though it omits any routing sentence that would have earned 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 rich annotations, an output schema, and fully documented parameters, the description only needs to convey scope — which it does via 'visible' and 'current work-unit snapshot'. The missing piece is sibling differentiation against get_entity_context and get_product_master.

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 both parameters (including the enum and the 'exactly as the user wrote it' requirement) are already documented in the schema. The description adds only a restatement of the accepted entity kinds, and notably lists 'brand', which is not one of the enum values (supplier/category/product) — a mild inconsistency rather than added 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?

States a specific verb ('reads') and resource set ('product rows, commercial measures and evidence') scoped to an entity in the current work-unit snapshot. Clear, but it does not distinguish itself from close siblings like get_entity_context or get_product_master, leaving the agent to infer the boundary.

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 when-to-use guidance is given. The phrase 'current work-unit snapshot' hints at a scoping condition, but the description never says when to pick this over get_entity_context, get_product_master, or search_catalogue, nor does it name any exclusion.

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 covered. The description adds genuinely new behavioral context beyond that: results reflect a point-in-time work-unit snapshot, and outlet breakdown and aggregation are deliberately absent, which shapes what an agent should expect from the output.

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 positive scope stated before the exclusions. Every clause carries information an agent can act on.

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 an output schema present, return values need not be explained, and annotations cover the safety profile. The description supplies the essential scope and limitation context; only explicit guidance on when to prefer this over other inventory-related views is missing.

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

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

Schema description coverage is 100% and both parameters are optional, so the schema already documents 'category' and 'entity_name' semantics fully. The description adds nothing about how these filters interact with the snapshot scope, making the baseline 3 correct.

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 ('Reads stock and inventory measures for products') plus the scope ('current work-unit snapshot'), which is far more than the tautological title. It does not name a sibling tool, but the negative scope ('no outlet breakdown or aggregation') implicitly separates it from any tool that would offer those views.

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 the tool is appropriate by bounding the data it returns, but it never states an explicit when-to-use condition or names an alternative tool for outlet-level or aggregated inventory. Usage must be inferred from the scope limitation.

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 read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds that this is advisory playbook content rather than transactional data, which is useful framing, but it says nothing about how the principles are scoped, ranked, or bounded — an output schema exists, so return shape need not be explained.

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

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

A single front-loaded sentence with the verb and resource first, followed by the qualifying examples. The situation list is long but each item earns its place by widening the recognisable trigger conditions; the extra 'such as ... or ...' chaining is slightly heavier than needed.

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 retrieval tool with a fully documented schema and an output schema, the description covers purpose and trigger conditions adequately. Only a note on how results should be interpreted or scoped (e.g. that these are guidance principles, not data) would close the remaining gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description goes further by enumerating the situation categories that constitute a valid 'topic', effectively hinting at the input space beyond the schema's single free-text example — real added value for a free-form string 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?

States a specific verb ('Retrieve') and a specific resource ('category-management playbook principles'), plus the situations that make them relevant. It is clearly distinct from the data-fetching siblings (get_product_master, get_sales_metrics, get_inventory_position), but it never names an alternative, so the differentiation is implicit rather than explicit.

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

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

The enumerated situations (supply disruption, slow sales, stock pressure, competitor moves, ranging, pricing) give the agent clear context for when this tool applies. It stops short of exclusions or pointing to sibling tools for related data, so it is context without boundaries.

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, and openWorldHint=false, covering the safety profile. The description adds that output includes calendar IDs, sources, and revisions, which is useful context beyond what annotations provide, but doesn't discuss rate limits or auth needs.

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 that is front-loaded with the core action and scope, then lists output fields. No redundancy or filler. Could be slightly more structured with separate sentences for action and return values.

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 explained, but the description does describe key output fields anyway. For a read-only tool with full schema coverage and annotations, this is nearly complete; only usage guidelines are missing.

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

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

Schema description coverage is 100%, so the schema fully documents all four parameters with patterns and the enum for type. The description mentions 'date window' and 'one remit' which map to starts/ends and bookKey, but adds no syntax or format details beyond the schema.

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

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

States a specific verb ('Reads') and resource (calendar entries in a date window) with scope detail ('for one remit'). Clear enough that no sibling tool overlaps, but doesn't explicitly distinguish itself from other read tools in the list.

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 when-to-use or when-not-to-use guidance. It mentions three calendar types but doesn't say when to pick this tool versus siblings like get_project or get_inventory_position. The agent must infer usage from the name alone.

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 fully cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds a genuine behavioral constraint beyond the structured fields: results are limited to the current work-unit snapshot and out-of-snapshot products are excluded, which is real value for interpreting completeness of results.

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 waste: the first states what is read, the second states the scope limitation. The most important constraint (snapshot boundary) is front-loaded alongside the field list.

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-value documentation is not required, and the description is sufficient for correct invocation. It is close to complete, though it could say a bit more about how the three filters combine or whether the read is always scoped by entity.

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 three filter parameters (category, entity_name, supplier_name) are already documented in the schema; the baseline of 3 applies. The description adds no syntax, matching behavior, or interaction semantics for these filters beyond what the schema 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?

The description gives a specific verb ('Reads') plus the resource (products) and names the field groups returned (price, cost, margin, lifecycle), so an agent knows what the tool surfaces. It does not, however, explicitly contrast itself with nearby siblings such as twelfth_list_products or get_inventory_position.

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

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

Usage is implied by the 'current work-unit snapshot' scoping statement, which signals the context in which results are valid, but there is no explicit when-to-use or when-not-to-use guidance and no alternative tool is named. An agent must infer routing decisions on its own.

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, closed-world, non-destructive behavior, so the safety profile is covered. The description adds genuinely non-redundant context: the ranking is 'precomputed' and scoped to the 'current work-unit snapshot', telling the agent results may be stale relative to live data.

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, with the positive scope and the key limitation front-loaded. 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?

An output schema exists, so return values need not be explained, and the read-only nature is covered by annotations. Minor gap: the description says 'category or supplier' while the parameter is generically named 'entity_name', leaving slight ambiguity about what entity types are accepted.

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 metric, category and entity_name with defaults and formats. The description only echoes the metric choices ('revenue or units') and the category/supplier scoping, adding little beyond the structured fields, so 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 (ranks) and resource (products) plus the exact scope: a named category or supplier within the current work-unit snapshot. The negative constraint 'It does not rank the whole catalogue' crisply bounds the tool, so an agent can distinguish it from catalogue-wide siblings like search_catalogue.

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

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

Usage is implied by the scope statement, but there is no explicit when-to-use guidance or named alternative (e.g. vs twelfth_list_products or search_catalogue). The 'does not rank the whole catalogue' clause hints at when-not, but doesn't route the agent to the correct 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 readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds the meaningful access constraint 'visible' (results are permission-scoped) but nothing about failure modes for non-visible or missing ids.

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

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

One sentence, front-loaded with the verb and resource, with no wasted framing. The trailing enumeration of returned facets is mildly 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 read-only, single-parameter tool with an output schema and full annotation coverage, the description supplies everything needed to select and call it. Only the explicit relationship to sibling read tools is missing.

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

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

Schema description coverage is 100% and the single projectId parameter is fully documented in the schema, including the UUID pattern and provenance ('from THIS PROJECT or a project link'). The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb ('Reads') and resource ('a visible Twelfth project') and enumerates the returned facets, so an agent knows exactly what this retrieves. It does not explicitly contrast itself with siblings like twelfth_list_projects or twelfth_get_workspace, so it falls short of the top score.

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 name/verb 'Reads ... project' plus the required projectId implicitly tells the agent this is the single-project fetch to use after obtaining an id from twelfth_list_projects. However, there is no explicit when-to-use statement or named alternative, so usage must be inferred.

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, non-destructive behaviour, so the bar is lower. The description still adds genuine context beyond them: the values are 'precomputed' and scoped to 'the current work-unit snapshot', signalling data freshness and isolation limits an agent would otherwise have to guess.

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, no filler, with the core purpose front-loaded and the limitation carried in the second sentence. Every clause 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?

An output schema exists, so return-value detail is unnecessary. The description covers what is returned, the snapshot scope, and the two things it does not do, which is enough for a low-complexity, zero-required-parameter read tool. Only the absent sibling routing 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 description coverage is 100%, so the schema already explains 'category' and 'entity_name' fully, setting the baseline at 3. The description adds nothing about how these filters interact (e.g. whether entity_name is required, or how category narrows lines), so it neither helps nor harms.

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

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

Names a specific verb and resource with real precision: 'reads precomputed revenue, units and margin per product', and scopes it to 'the current work-unit snapshot'. An agent knows exactly what data comes back. It does not explicitly differentiate itself from any sibling by name, which keeps it just below a 5.

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

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

The second sentence supplies useful negative guidance ('no date series or whole-workspace totals'), which tells the agent this is not the tool for trends or aggregate rollups. However, no alternative tool is named for those cases and there is no positive 'use this when' framing, so the routing guidance remains implied 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 readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the 'visible' qualifier, hinting results are authorization-filtered, but says nothing about scope limits, defaults, or how the supplier/product rows relate. Modest added value over 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 short sentences, purpose first then usage, with no redundant filler. It is appropriately sized, though the second sentence is doing double duty for both purpose and routing without resolving either fully.

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 an output schema present, return values need not be explained, and the schema fully documents both parameters. Annotations cover the safety profile. The remaining gap is that zero required parameters means the tool can be called with no arguments, and the description never clarifies the default/no-entity 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?

Schema description coverage is 100%, so both parameters are fully documented in the schema and the baseline is 3. The description does not add syntax, format, or default behavior for entity_name or include_stock_value beyond what the schema already states (it only echoes the inventory-capital framing for include_stock_value).

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 verb (Read) and resources (supplier information and product rows), but the name/title promise 'constraints' while the body talks about general supplier info and product rows, creating a mismatch. It does not distinguish this tool from sibling find_supplier, which an agent would plausibly choose instead.

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

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

'Use for supplier range, constraints, or inventory-capital questions' gives implied usage triggers, which is better than nothing. But it names no alternatives and no exclusions, so the agent gets no routing help against siblings like find_supplier, compare_supplier_offer_history, or get_inventory_position that also touch supplier/inventory questions.

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 and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: each page is capped at 24,000 characters and the call returns text, page count and document details, which tells the agent how to chunk reads.

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

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

Two compact clauses, zero filler. The core action and scope come first, and the return/limit detail follows, so the reader is front-loaded with what matters.

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 a full output schema and rich annotations, the description only needs to carry scope and behavioral quirks, and it does. The one missing piece is routing relative to search_docs, which matters given how many sibling tools operate on documents.

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 both parameters (page, documentId) are already documented in the schema with defaults and bounds. The description's 24,000-character note adds context about page sizing but no new syntax or format details. 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 ('Reads one page of a document') and adds scope ('shared with the connected Twelfth workspace'), which is enough for an agent to identify it. It does not, however, distinguish itself from the sibling search_docs, which likely also touches documents.

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

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

Usage is implied: read a page of a document you already have the id for. There is no explicit when-to-use guidance, no mention of the search_docs alternative, and no statement of prerequisites beyond the implicit 'shared workspace' constraint.

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 covered. The description does add one useful behavioral detail the annotations do not: results come from the 'readable' catalogue, implying permission-scoped visibility, and it links to open recommendations. It says nothing about result volume, ranking or pagination beyond what the schema's limit field implies.

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 filler, with the primary action and scope front-loaded and the recommendation filter as a secondary clause. 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?

An output schema exists, so return values need not be described. The description covers scope and the filter surface, but it omits any note about how matches are ranked or what happens when no filters are supplied (all params optional), leaving a small gap for a zero-required-parameter search tool.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters in detail (including the 'every word must appear' semantics for query). The description only restates the filter axes and adds no syntax or matching nuance beyond the schema, so the baseline 3 applies.

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

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

Specific verb (searches) plus a clearly scoped resource (the connected workspace's readable product catalogue) and the three filter axes (text, supplier, category). It distinguishes itself reasonably from generic listers like twelfth_list_products, though it never explicitly names or contrasts a sibling such as find_similar_products.

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 second sentence states a capability ('can limit results to products with open recommendations') rather than when to use this tool instead of alternatives. No when-not guidance and no alternative tool is named, so the agent must infer the selection context.

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

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

Annotations already establish read-only, idempotent, closed-world, non-destructive behavior, so the bar is lower. The description earns credit by adding the empty-result contract and the fact that it returns matching sections plus links rather than full content, which is meaningful behavior 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 tightly packed sentences; the purpose and the return/empty-result contract are front-loaded with zero 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?

An output schema exists, so return values need not be spelled out, and the description still sketches them usefully. The one gap is routing relative to read_document and search_catalogue, which matters for correct tool selection in this crowded sibling set.

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 both parameters (query, limit) are already fully documented, including the plain-language guidance and the 1-10 bound. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource (searches Twelfth product documentation for pages, controls and settings), which is clear and actionable. However, it never distinguishes itself from the sibling read_document or search_catalogue, so an agent must infer which search surface applies.

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: the description tells you the corpus is product documentation pages/controls/settings, and that an empty result means nothing matched. It gives no explicit when-to-use, prerequisites, or routing to read_document for pulling the full page behind a returned link.

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 valuable behavioral context beyond that: the OAuth-connection prerequisite for personal/membership scopes, which is not in the annotations or 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 tightly written sentences, front-loaded with the core action and the scope constraint. No filler, though the second sentence is somewhat compressed and could clarify which tools replace it.

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?

Since an output schema exists, return values need not be explained. The description covers the auth prerequisite and scope routing, leaving only minor gaps around how the alternate tools are named.

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 scope parameter is fully documented in the schema, including the enum meanings and the workspace-key constraint. The description adds no parameter syntax or format detail, so the baseline 3 applies.

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

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

States a specific verb+resource (read stored preference values and valid keys) and immediately scopes it by excluding broader Settings pages. It does not name a specific sibling tool, so differentiation is by category description rather than by tool name.

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

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

Gives clear when-to-use context: personal and membership preferences require a person's OAuth connection, and service-backed settings like integrations and category remits are handled elsewhere. It routes the agent away from the wrong cases without naming the exact alternative 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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety and determinism profile is fully covered structurally. The description's one contribution is that the workspace is 'authorised by this connection', clarifying multi-workspace scoping, but it says nothing about caching, freshness, or failure when no workspace is authorized.

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

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

One sentence, front-loaded with the verb and resource, and every clause carries information ('identity', 'operating defaults', 'authorised by this connection'). Nothing redundant or padded.

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-value detail is not required, and there are no parameters to document. What remains thin is the sibling-relationship context: whether this is the canonical entry point for workspace metadata versus twelfth_get_preferences is left unstated.

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 of 4 applies; there is no parameter surface for the description to clarify. The description's mention of connection-derived scoping does at least confirm the workspace is resolved implicitly rather than passed in.

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 ('Get the identity and operating defaults of the Twelfth workspace') and scopes it to the connection-authorized workspace, which is more precise than a bare 'get workspace'. It does not, however, differentiate itself from near-siblings such as twelfth_get_preferences, whose remit ('operating defaults') plausibly overlaps.

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, when-not-to-use, or alternative routing. With twelfth_get_preferences and twelfth_list_workspace_members in the same family, an agent gets no help deciding which to call for workspace-level information.

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 confirm readOnlyHint=true and idempotentHint=true, so safety is already established. The description adds valuable context beyond annotations: remit details are narrowed to the person's readable books, category management is owner/admin-only, and demand overrides require Twelfth staff. This explains permission scoping and access limitations that an agent otherwise wouldn't know.

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 dense sentences with no filler. The access-scoping constraints are front-loaded. Dense but each clause adds information; not quite maximally structured as the second sentence packs multiple conditions.

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 an output schema present, return values needn't be described. The description covers scope (what's visible, what's narrowed), permission model (owner/admin, Twelfth staff), and safety is covered by annotations. Complete for a read-only, parameterless listing.

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 parameters, so baseline is 4 per the rules. The description appropriately focuses on scope and visibility rather than parameter details, which is the correct tradeoff for a parameterless tool.

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 (Read) and resource (managed categories, aliases, remit ownership). Distinguishes from siblings by focusing on category settings rather than products, projects, or workspace members, but doesn't name an alternative tool that might also list categories.

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 'visible to this connection' implies scope, and 'owner/admin-only in the app' suggests when write operations occur, but there's no explicit when-to-use vs alternatives or when this is the wrong tool. Usage is implied rather than stated.

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 openWorldHint=false, so the safety profile is covered. The description still adds value by explicitly scoping out OAuth initiation and connection mutation, preempting a common misreading of an 'integrations' tool as one that can connect accounts.

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 filler. The capability statement comes first and the scope-limiting constraint is front-loaded as the second sentence, so the agent gets the important boundary immediately.

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 simple (no parameters, read-only) and an output schema exists, so the description does not need to explain return values. It covers purpose and the key non-action boundary; the only minor gap is that it does not hint at the shape or grouping of the returned guides, which is reasonable to leave to the output schema.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-param tool is 4. Schema coverage is 100% and the empty object schema is self-explanatory.

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 pair (list integration guides) plus the substantive content of the result: which data/chat integrations are connected, what each provides, and where to configure it. No sibling tool covers integrations, so no differentiation is needed and the agent can select it unambiguously.

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

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

Provides a clear negative boundary: it never starts OAuth or changes a connection, which tells the agent this is purely informational and must be paired with a separate tool for any connection change. There is no named alternative sibling because none exists, so the guidance is context without an explicit routing choice.

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, and destructiveHint=false, so the safety profile is fully covered by structured data. The description only adds the workspace scoping and the shape of the payload, saying nothing about pagination, result limits, or what counts as 'open'.

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

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

A single front-loaded sentence with the verb and scope first and the returned fields appended. No filler, no restatement of the title, nothing that fails to earn 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 zero-parameter read-only listing with an output schema, the description covers purpose, scope, and payload contents adequately. It is only marginally incomplete in not clarifying the boundary against the workflow/project list siblings or the meaning of 'open'.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate, though it also gives no hint about implicit server-side defaults such as sorting or which statuses qualify as open.

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

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

Names a specific verb+resource ('List ... open actions') and scopes it to 'this workspace', plus enumerates what comes back (due dates, assignees, work-unit context). It does not differentiate itself from the similarly-named twelfth_list_project_workflows or twelfth_list_projects, so an agent must infer the boundary from the noun 'actions'.

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 when-to-use, when-not-to-use, or alternative-tool guidance; the sentence only describes what is returned. The agent must guess that this is the tool for retrieving outstanding task items rather than anything derived from the workflow or project listings.

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, non-destructive and closed-world behavior, so the bar is lower. The description still adds genuine context: it discloses the returned facets (position, supplier, category, open finding count) and the null semantics for unmeasured figures, which is non-obvious behavior not derivable from 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, zero filler, and the scope is front-loaded before the return facets and null caveat. Every sentence 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?

With 8 optional params, full schema coverage, an output schema, and rich annotations, the description only needs to supply scope and behavioral caveats, which it does. The null-figure note and remit scoping close the main gaps; explicit routing against sibling search tools is the one omission.

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 per-parameter descriptions, defaults, and enum values, so the schema does the heavy lifting. The description mentions remit scoping but adds no syntax, format, or interaction detail beyond what the schema already states; 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 pair ('Page through the Products portfolio') and adds a scoping constraint ('this connection's readable remits'). It does not explicitly distinguish itself from siblings like search_catalogue, get_product_master, or get_product_ranking, so an agent must infer the list-vs-lookup 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?

Usage is implied by the paging/listing shape and the remit scoping, but there is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. An agent can guess this is the enumeration entry point, but nothing confirms it against search_catalogue or get_product_master.

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 only the visibility constraint ('this connection's workspace and remits'), and says nothing about pagination, result volume, or ordering.

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

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

A single front-loaded sentence with the scope constraint stated up front and no filler. Nothing to trim.

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 annotations carry the safety profile; the remaining gap is routing guidance versus get_project. For a two-optional-parameter list tool this is nearly complete.

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

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

Schema description coverage is 100% and both parameters (state enum with default, workflow key) are already documented in the schema, including the pointer to twelfth_list_project_workflows. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb+resource ('List projects') and adds real scope: what is visible to this connection's workspace and remits. It is distinguishable from get_project (single-project read), though it never names siblings explicitly.

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

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

There is no when-to-use or when-not-to-use guidance, and no alternative is named even though get_project and twelfth_list_project_workflows are obvious adjacent choices. The visibility scoping hints at the discovery use case but does not guide selection.

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 the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description need not restate that. It adds a small amount of behavioral context by noting that availability is included in the results, but says nothing about ordering, filtering, or what a workflow object represents.

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 short sentence with no waste, and the resource is front-loaded. It is efficient, though arguably under-specified rather than optimally concise.

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 zero parameters and an output schema present, the description does not need to explain return values. The main gap is the absence of any routing guidance relative to the many similarly named sibling list tools.

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 schema baseline of 4 applies. There is nothing for the description to clarify beyond that.

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 ('List project workflows') plus a scope detail ('this workspace offers, including their availability'). It is clear what the tool does, though it does not distinguish itself from the sibling twelfth_list_projects, which an agent could easily confuse it with.

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 guidance on when to use this tool versus twelfth_list_projects or twelfth_list_open_actions, and no prerequisites or context are given. The agent must infer usage entirely from the name.

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 covered. The description usefully adds the scope constraint ('the workspace authorised by this connection'), implying results are limited by the caller's authorisation, but it says nothing about pagination, ordering, or result limits.

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 identifies the resource, the returned fields, and the access scope with zero filler. Nothing is padded or repeated from the title.

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 read-only listing with an output schema and full annotation coverage, the description is essentially sufficient. The only minor gap is that it doesn't state whether the list can be large or paginated, but the output schema can carry that.

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. There is nothing for the description to disambiguate and it correctly avoids inventing parameter semantics that do not exist.

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 verb ('List') and resource ('the people and their roles in the Twelfth workspace'), so an agent knows exactly what the tool returns. It adds scope ('authorised by this connection') but does not explicitly differentiate itself from the nearby sibling twelfth_get_workspace, 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?

There is no stated when-to-use guidance, no prerequisites, and no mention of the obvious alternative (twelfth_get_workspace) or how this differs from other twelfth_list_* tools. Usage is only inferable from the name, which is no guidance at all.

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