PolicyTrak

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 genuine behavioral value beyond that: the return is base64 bytes and is capped at 10 MiB, which is a real constraint an agent must plan around. It would be a 5 if it said what happens at the size limit (truncation vs. error), but the added constraint is substantive.

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, and the action is front-loaded before the return detail. Every clause carries information the 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 single-parameter tool with annotations and an output schema, the description covers what the tool does, how it is keyed, and its payload shape and cap. The remaining gap is the error/truncation behavior at 10 MiB and how the ID is sourced, but the output schema carries the return-value burden.

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

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

There is one parameter at 0% schema description coverage, so the description must compensate. 'By saved ID' tells the agent this is an identifier of a previously saved attachment rather than a path or URL, but adds nothing about the format constraints (pattern, 1-128 chars) or where the ID is obtained, leaving the single parameter only partially explained.

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 ('Download a field attachment') plus the keying mechanism ('by saved ID'), which separates it from the list_field_attachments sibling. It does not explicitly distinguish itself from other download_* siblings (download_resource, download_location_document), so the differentiation is inferred from the resource noun 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?

Usage is only implied: 'by saved ID' hints that an ID must come from somewhere (presumably list_field_attachments), but the description never says to call that first or when to prefer this over the other download tools. No exclusions or prerequisites are given.

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

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

Annotations already declare this a safe, idempotent, closed-world read, so the bar is lower. The description still adds substantive behavior beyond them: base64 return encoding, a 10 MiB size ceiling, and a security constraint that arbitrary paths are rejected.

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 and the most consequential constraint (saved ID only) front-loaded.

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

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

An output schema exists, so return-value detail needn't be spelled out, and annotations cover the safety profile. However, the role of locationId and whether it must be consistent with the document's location is unaddressed, which is agent-relevant for correct invocation.

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

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

Schema description coverage is 0%, so the description carries full burden here. It adds real meaning for docId (a saved ID, explicitly not a filesystem path) but never mentions locationId or its relationship to docId, leaving half the required parameters undocumented anywhere.

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

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

States a specific verb and resource ('Download a site document by its saved ID'), which clearly separates it from list_location_documents. It does not explicitly distinguish itself from the other download/export siblings (download_field_attachment, download_resource), leaving the agent to infer from the resource 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?

Usage is only implied: 'by its saved ID' suggests the ID must come from a listing call first, and the 'never accepts arbitrary paths' line implicitly excludes path-based lookups. No explicit when-to-use or how-this-differs-from-alternatives guidance is given.

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

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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the safety profile is clear. The description adds one useful behavioral constraint, the 10 MiB size limit, but does not explain what happens if the limit is exceeded, auth requirements, or return format.

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 the key action and constraint front-loaded. No wasted words.

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. However, the only parameter is undocumented in the description despite 0% schema coverage, and error behavior around the size limit is not addressed. Adequate but with clear gaps.

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

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

Schema description coverage is 0% for the single resourceId parameter. The description says 'a library resource' but does not clarify that resourceId identifies it, nor does it add any format or usage detail beyond what the schema's pattern and length constraints already enforce.

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 (Download) and resource (library resource), and adds a concrete size limit. It distinguishes itself reasonably from metadata-oriented siblings like get_resource, though it does not explicitly contrast with download_field_attachment or download_location_document.

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 guidance on when to use this tool versus alternatives such as get_resource or the other download tools. The intended use is implied only by the verb and resource phrasing.

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 one genuine behavioral constraint — only approved export items are included — but says nothing about whether the export is synchronous, whether it fails on an empty/unapproved book, or where the artifact lands. 'Generate' is not a contradiction of readOnly since no stored resource is modified.

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 well-formed sentence with no filler; the object and scope are front-loaded. It is efficient but arguably too terse for the gaps it leaves, though that is penalized elsewhere.

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 one parameter and an output schema present, return-value explanation is unnecessary, and the description covers the core action. However, for an export tool it omits the practical essentials an agent needs: what 'approved' means, failure conditions, and how to supply the book identifier.

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

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

Schema description coverage is 0% for the single bookId parameter, and the description never mentions it directly or explains its format/source (e.g., obtainable from list_books). The only implicit link is 'a book PDF', which leaves an agent to infer that bookId is the target book's identifier.

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 (Generate) and resource (book PDF) with a scope qualifier (approved export items), which cleanly distinguishes it from siblings like export_policy_pdf and export_sop_pdf that operate on other document types. It stops short of explicitly naming those alternatives, but the resource noun does the differentiating work.

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 versus export_report, export_sop_pdf, or the list_books/get_book siblings, and no prerequisites are stated. The phrase 'approved export items' hints at a precondition but never says what it means or what happens if none exist.

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, so the safety profile is covered. The description adds a genuine behavioral fact beyond the annotations: the caller needs the contacts.read scope, which is exactly the kind of auth requirement structured fields cannot express.

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 the purpose front-loaded and the permission note trailing it — no waste. The word 'additionally' is slightly ambiguous (additional to what baseline permission?), costing a point but not clarity of the core action.

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 exporter with an output schema and full annotations, the description supplies everything needed to call it correctly: what it produces and what scope it requires. It omits only marginal detail like file size limits or whether generation is synchronous.

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 no parameters, so there is nothing for the description to disambiguate; this is the baseline-4 case. No parameter text is expected or missing.

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 the output format: 'Download organization contacts as CSV'. The resource word 'contacts' cleanly separates it from the sibling exporters (export_employees_csv, export_locations_csv, export_policy_pdf) without needing their schemas opened.

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 states a permission prerequisite ('additionally requires contacts.read') but gives no guidance on when to choose this over alternatives such as list_company_members or get_contact_tab_access, and no exclusions or context for the export.

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 that this is a safe, read-only, idempotent export. The description adds a meaningful behavioral requirement beyond that: the caller must additionally have employees.read. It does not discuss rate limits or output shape, but the output schema covers the return value.

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 compact sentence front-loads the core action and appends the key permission requirement. No unnecessary text.

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, zero parameters, and annotations covering safety, the description is nearly complete for correct invocation. The missing piece is explicit routing guidance among the many export siblings, but the core behavior and permission prerequisite are covered.

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 burden on the description. Schema coverage is 100% and the description correctly does not invent parameter details.

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

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

The description states a specific verb and resource: download organization employees as CSV. It is clearly distinguishable from sibling exports like export_contacts_csv or export_locations_csv by the resource, though it does not explicitly call out those alternatives.

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 employee/CSV scope implies when to use this tool, but there is no explicit guidance on when to prefer it over related export tools or when it should not be used. The permission note is useful but is not a usage condition in the workflow sense.

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 the safety profile is covered. The description does add genuine behavioral content — that live labels, answers and exception tags are preserved, i.e. the export is a faithful render — but says nothing about permissions, output size limits, or what happens when no template is supplied.

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

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

Two compact sentences with the purpose front-loaded and no filler. Slightly under-specified rather than verbose, which is the better failure mode here.

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 introduces a phantom templateId parameter and leaves locationId and the freeform 'data' object uncharacterized. For a nested-object tool with an opaque additionalProperties schema, an agent needs more to construct a correct 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?

Schema description coverage is 50%, and the undocumented required parameter (locationId) gets no explanation in the text. Worse, the description advertises an optional 'templateId' and 'export selections' that do not appear in the input schema at all, so the prose sends the agent looking for parameters that don't exist while the real 'data' object is described only generically.

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 ('Export the site's PDF') and adds what fidelity is preserved (live labels, answers, exception tags), which tells an agent this is a rendered/annotated location export rather than a raw dump. It does not however distinguish itself from the many sibling PDF exports (export_book_pdf, export_policy_pdf, export_sop_pdf), leaving the agent to infer the difference from the 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?

There is no statement of when to use this versus alternatives — notably list_location_pdf_templates, which would be the obvious prerequisite for choosing a template, or the other PDF exports. The only usage hint is 'Optional templateId', which is expressed as a fact rather than guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety profile is covered. The word 'organization' adds scope context (org-wide, unfiltered), but no mention of file size, rate limits, or auth needs; an output schema covers the return.

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

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

A single front-loaded sentence with no waste. However, given the many sibling exports, it is arguably too terse to be maximally helpful.

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?

A zero-param export with full annotation coverage and an output schema needs little more. The description is adequate, though a note on scope versus the PDF/location-filter siblings would round it out.

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?

Zero parameters, so the baseline is 4. The description adds nothing needing explanation, and there is no schema surface to clarify.

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 (Download/export), resource (organization locations), and output format (CSV). This distinguishes it from PDF location exports and from contacts/employees CSV exports among siblings, though it doesn't explicitly name those alternatives.

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

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

No explicit when-to-use or when-not guidance, nor any named alternative. For a zero-parameter export the implied usage is fairly clear, but the agent must infer how this differs from export_location_pdf or list_locations.

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 the safety profile is covered. The description adds nothing beyond that – no mention of whether generation is synchronous, whether the PDF reflects the latest policy version, or any auth/premium gating. With annotations doing the heavy lifting, the description still leaves a behavioral 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?

One short, front-loaded sentence with zero padding, which is good structurally. However, the brevity comes at the cost of under-specification rather than being earned conciseness.

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 explanation is not required. Still, for an export tool the description should note the output format/layout source (e.g., company document styles, location PDF templates) or versioning behavior; none of that is present, leaving the agent with only the name to work from.

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

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

Schema description coverage is 0% and the single parameter policyId has constraints (pattern, max length) documented only in the schema, not prose. The description never mentions what identifier to pass or where to obtain it, so it fails to compensate for the coverage gap even though there is only one 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 'Generate a policy PDF' essentially restates the tool name export_policy_pdf with a verb swap. It conveys the output format (PDF) and resource (policy) but does nothing to distinguish this from export_policy_word or export_sop_pdf, which share the same verb family.

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, no prerequisites, and no mention of the obvious siblings (export_policy_word, export_sop_pdf). The agent must infer from the name alone that this is the PDF variant for policies rather than SOPs or Word exports.

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 nothing about what 'generate' produces behaviorally — whether a stored document is created, whether it is written to a location, or whether repeated calls regenerate or reuse output — which is exactly the context annotations can't supply.

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

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

One short, front-loaded sentence with zero waste. Brevity here is not padding, though the sentence is too thin to earn a top score.

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?

Output schema exists so return values needn't be explained, but for a single-required-param export tool the description leaves the parameter meaning and format-choice rationale entirely unaddressed, which is not enough to invoke confidently.

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

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

Schema coverage is 0%: policyId carries only pattern/length constraints and no description. The description never mentions policyId, so the agent gets no guidance on what identifier is expected (policy id vs. version vs. workspace) — a clear compensation gap 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?

States a specific verb (Generate) and resource (a policy Word document), and the 'Word' qualifier implicitly separates it from export_policy_pdf / export_sop_pdf siblings. It never explicitly names the alternative format tool, 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?

No statement of when to choose Word over the sibling PDF export (export_policy_pdf) or when to use export_sop_word instead. The agent must infer format preference from the tool 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 cover the safety profile (readOnly, idempotent, non-destructive). The description adds meaningful context beyond them: the return is file bytes rather than a public link, and it discloses the required reports.read and employees.read scopes for mixed data. Good additive value.

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 compact sentences, front-loaded with the core action, then return format, then permissions. No wasted text.

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?

Output schema exists, so return values needn't be detailed, and annotations plus permission notes round out behavior. The only real gap is that nested format parameter semantics are left entirely to the 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?

Schema description coverage is 0% and there are two parameters, including a nested data object with a format enum. The description mentions neither reportId nor the format option, so it does not compensate for the undocumented 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 concrete verb+resource: "Run and export a report." It also clarifies the output form (file bytes, not a public link), which helps separate it from the preview_report/get_report siblings, though it never names those alternatives 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 "Run and export" and the file-bytes output clarification, but there is no explicit when-to-use guidance or reference to alternatives like preview_report or get_report. The agent must infer when to export vs preview.

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 nothing behavioral beyond that: it doesn't say whether the call returns a URL, bytes, or an async job, nor whether the export is synchronous. The readOnly annotation is not contradicted, so this is a thin description rather than a contradiction.

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

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

A single four-word sentence with zero waste and the resource front-loaded. But the brevity stems from shortchanging important content, not from disciplined editing.

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

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

An output schema exists, so return values needn't be explained. But with a mutation-adjacent export of one undocumented identifier, a thin annotation set, and 0% parameter coverage, the agent still lacks the details needed to invoke this confidently or distinguish it from the Word and policy export 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 one parameter, sopId, with 0% schema description coverage — only a regex pattern and a length bound are documented. The description says nothing about what sopId refers to, whether it is the SOP's numeric id or a slug, or what happens if it's invalid, so it fails to compensate for the coverage gap.

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

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

The description reads 'Generate an SOP PDF', which is essentially the tool name 'export_sop_pdf' restated in sentence form. It does name a verb and a resource, but adds no scope, no sibling differentiation, and nothing an agent couldn't infer from the name 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?

No when-to-use guidance at all. Siblings such as export_sop_word, export_policy_pdf, and export_policy_word exist, yet the description never indicates when a PDF is preferred over Word, or when one should use get_sop instead of exporting.

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 covered. The description adds nothing beyond them: it doesn't say whether generation is synchronous, what happens for an unknown sopId, or where the produced file goes, despite this being a document-generation action an agent may need to poll or retry.

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

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

One short sentence with zero filler, front-loading the action and output. It is efficient but so terse that conciseness is achieved by omission rather than by tight phrasing.

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 and annotations exist, so return values and safety need not be restated, but for an export tool the description should at minimum name the ID source and note the generated format/behavior. Neither is present, leaving meaningful gaps for an agent to fill.

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

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

Schema description coverage is 0%, so the single sopId parameter has no documented meaning anywhere. The description could have said it is the SOP identifier retrievable via list_sops/get_sop, but it does not, leaving the agent to infer how to obtain a valid ID.

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 (generate) and resource (SOP Word document), which implicitly distinguishes it from the PDF variant among siblings. It is clear what the tool produces, but it never explicitly contrasts itself with export_sop_pdf or export_policy_word.

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

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

No guidance on when to use this versus export_sop_pdf, export_policy_word, or get_sop. There are no prerequisites stated (e.g., whether the SOP must exist or be published) and no exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is carried by structured data. The description's real contribution is the auth requirement (state_guide.read) and the Excel output format; it says nothing about export size, latency, or whether a prior row/column filter applies.

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

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

One sentence, no filler, with the action and permission constraint front-loaded. 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 values needn't be described, and the auth prerequisite is stated. For a zero-parameter export tool this is close to complete; minor gaps are whether filters/columns must be configured beforehand and what the file contains.

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

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

The tool takes zero parameters and the schema is fully covered, so there are no parameter semantics for the description to compensate for. Baseline 4 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 (export), resource (the organization's State Guide), and output format (Excel), which implicitly separates it from the PDF/Word/CSV export siblings. It stops short of naming a sibling explicitly, so 4 rather than 5.

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

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

No explicit when-to-use or when-not guidance and no named alternatives among the many export_* siblings. The permission prerequisite ('requires state_guide.read') gives some operational context, but the agent must infer that this is the right export tool for the State Guide specifically.

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 cover safety (readOnly, idempotent, closed-world), and the description adds substantial behavior beyond that: search order ('labels, keys and tabs before scanning'), what is returned ('exact saved evidence, unknown/missing counts and pagination'), exclusions ('masked fields and restricted records are excluded'), and pagination contract ('Honor complete/hasMore').

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

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

Front-loads purpose, then the example, then operator semantics, then exclusions and pagination — a sensible order for a 10-param tool. The operator enumeration is dense but earns its place; a few sentences are run-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?

An output schema exists so return values need no explanation, and annotations cover the safety profile. What remains is query semantics, exclusions, and pagination, all present; only the state/locationSearch filters and empty-result behavior are unaddressed.

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

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

Schema coverage is 0%, so the description carries the load and does so for the core params: condition operator families, compareValue/compareTo pairing, combine:'and'/'or' with a 5-filter cap, and a fieldSearch example. It leaves state and locationSearch unexplained, so it does not fully compensate.

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 ('Find sites') plus the mechanism ('saved Details-tab fields, not web research'), which immediately separates it from free-text search or list_locations. An agent can tell what this tool does without opening the schema.

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

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

Gives a concrete worked example ('For plastic bag bans use fieldSearch:plastic bag, condition:ban') and a disambiguation rule ('Fees/proposals are not bans'), which is real when-to-use guidance. It stops short of naming an explicit alternative sibling for simpler listing needs, so it is not a full 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds the missing operational trait that matters here: the result set is paginated and the agent should 'paginate until hasMore=false'. It doesn't say what a page contains, but the output schema covers that.

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 tight sentences: what it finds, when to use it, how to consume the results. No filler and the identifying constraint (exact field keys) is front-loaded.

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

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

With an output schema present, the description needn't explain return values, and it correctly spends its words on the pagination loop instead. The only gap is what 'enqueue research' operationally entails and that unmatched keys are presumably dropped.

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

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

Schema description coverage is 0%, so the description must compensate and only partly does: it establishes that fieldKeys are exact-match and that offset/limit drive pagination via hasMore. It never mentions the 20-key array cap, the 100 default page size, or that keys are case-sensitive, leaving bounds to 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 ('Find saved field IDs across locations') and narrows the lookup to 'exact field keys', which separates it from the broad list_location_fields and the inverse find_locations_by_field. The sibling distinction is implied rather than named outright, keeping it 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?

'Use after bulk creation to enqueue research' gives a concrete triggering context, which is more than most definitions offer. It stops short of naming the alternative tool (e.g. list_location_fields) for agents who don't have freshly created keys.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds no behavioral context beyond the word 'Read'—it does not say what the summary contains, how it is scoped to the organization, or whether it aggregates acknowledgements 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, front-loaded sentence with no wasted words. Its brevity is appropriate, though it is arguably too sparse rather than overly verbose.

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 convey the safety profile. However, for a summary tool surrounded by similarly named acknowledgement tools, the description does not provide enough context to disambiguate its purpose or scope.

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 are no parameters whose semantics need explaining in 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?

States a specific verb ('Read') and resource ('organization acknowledgement summary'), but 'acknowledgement summary' is not differentiated from closely named siblings such as get_acknowledgment_overview, get_acknowledgement_tracking, and get_location_acknowledgement_summary. The organization scope helps somewhat, yet the description does not clarify what makes this summary distinct.

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 the several acknowledgement-related siblings. An agent cannot infer whether this is the right choice over get_acknowledgment_overview or get_location_acknowledgement_summary.

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. The description reinforces that this does not complete acknowledgements, which is useful but mostly restates the read-only nature rather than adding details such as scope, permissions, or return behavior.

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

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

It is a single compact sentence with the core action front-loaded and no wasted wording. It could still afford one clause distinguishing it from the acknowledgement summary/overview siblings.

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, annotations are rich, and an output schema exists, so much of the context is covered. However, with many similarly named acknowledgement-related siblings, the description leaves an important routing gap about when this specific tracking read is appropriate.

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

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

Schema description coverage is 0%, and the description does not explain documentType or documentId at all. The schema's enum and pattern give some constraints, but the description does not compensate for the missing semantic guidance needed to choose values correctly.

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 clear verb and resource: reading acknowledgement tracking for a document. It distinguishes itself from an acknowledgement-completion action, but does not distinguish itself from sibling tools such as get_acknowledgement_summary or get_acknowledgment_overview.

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

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

The description provides only a negative usage hint ('does not complete acknowledgements'). It gives no guidance on when to use this tracking read versus the many acknowledgement summary/overview/list siblings.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond restating 'Read' — no note on what the overview aggregates, its org-wide scope, or freshness/aggregation behavior — so it provides no value 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?

A single front-loaded sentence with zero filler; nothing wasted. It is arguably too terse for the ambiguity it leaves, but that is a completeness issue rather than a conciseness defect.

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, rich annotations, and an output schema covering return values, the definition is minimally sufficient to invoke. Still, the description never clarifies what the 'overview' contains or how it differs from the closely named acknowledgment summary/tracking tools, leaving real selection ambiguity in a 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly implies an implicit organization-wide scope rather than requiring a 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 gives a clear verb ('Read') and a specific resource ('organization acknowledgment overview analytics'), so the agent knows this is a read-only analytics retrieval. However, it offers no differentiation from near-identical siblings such as get_acknowledgement_summary, get_acknowledgement_tracking, or get_location_acknowledgement_summary, all of which plausibly return similar acknowledgment data.

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 the many acknowledgment-related siblings; the agent must infer from the name alone. No prerequisites, scope conditions, or exclusions are 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 establish read-only and idempotent behavior. The description goes further, disclosing permission boundaries (no approval capability, no exposure of the stored change) and the retry-after-approval semantics, though it says nothing about response shape or expiry semantics beyond existence.

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 tight sentences, front-loaded with the core action, then constraints, then next steps. No filler.

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

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

Output schema exists, so return values needn't be explained, and the safety profile is covered by annotations plus the permission disclaimer. The only real gap is parameter context, which leaves the definition nearly complete for a simple read tool.

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

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

Schema coverage is 0% and the single required parameter approvalId is never mentioned or explained in the description. The UUID format/pattern in the schema helps, but an agent gets no guidance on where the approval ID comes from or what it identifies.

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 and resource: check status and expiry of an app approval for this connection. Clearly distinguished from sibling approval tools (get_approval_request, list_approval_requests) by scope and by stating it cannot approve.

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 actionable workflow guidance: cannot approve or reveal the stored change, ask an Admin/Owner to review in the app, and retry the exact change only after approval. Doesn't explicitly contrast with siblings like get_approval_request, so not 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered elsewhere. The description adds nothing beyond that — no mention of aggregation scope, time window, or refresh/caching behavior that would help an agent interpret the result.

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

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

A single front-loaded sentence with no filler. It is efficient, though the terseness borders on under-specification rather than crispness.

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 output schema exists, so return formatting need not be explained, and the tool is parameterless. Still, the core ambiguity — what "adoption" means and over which population/timeframe — is left entirely unresolved, which is the one thing the description should have carried.

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, which is the baseline-4 case — there is nothing for the description to disambiguate. The absence of any filter argument is worth noting, but not a schema gap the description must fill.

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 restates the title almost verbatim ("Read organization adoption rates") and adds only the vague word "analytics". It never says what adoption is measured on (policies, modules, books, locations) or what unit/metric is returned, so an agent cannot distinguish it from siblings such as get_acknowledgement_summary or get_compliance_scorecard.

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 call this versus any of the many sibling analytics/summary tools. No prerequisites, no scope conditions, no alternatives are named.

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 fully covered. The description's only added behavioral fact is that the response bundles workflow data alongside the request, which is a modest but real contribution; nothing about not-found behavior or scope restrictions is disclosed.

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 the verb and resource front-loaded and no padding. It is arguably too terse rather than bloated, and the trailing "and its workflow" clause is the weakest part.

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 (one required ID param), annotations carry the safety profile, and an output schema documents return values, so the bar is low. Still, for a definition this short, the meaning of "workflow" and the not-found/error behavior are left entirely to the agent to discover.

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

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

Schema description coverage is 0%, so the description must compensate, and it does not — it never mentions the required approvalRequestId or what format a valid identifier takes. The parameter name is self-explanatory enough that an agent will likely guess correctly, but the description adds no semantic 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?

States a specific verb (read) and resource (an approval request), with singular scope that implies single-record retrieval versus the list_approval_requests sibling. However it never names a sibling explicitly, and "and its workflow" is a vague scope claim that doesn't clarify what related data is included.

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

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

No guidance on when to use this instead of list_approval_requests, get_action_approval_status, or list_approval_steps, all of which sit adjacent in the sibling list. The only cue is the singular article, which the agent must infer as 'fetch one by ID'.

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 description's 'Read' adds nothing beyond what structured data provides. With the annotation baseline met, the description contributes no extra context such as whether the template includes steps, whether it is versioned, or failure behavior for unknown 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 short, front-loaded sentence with no filler, so it passes on brevity. It is under-specified rather than bloated, which leaves the score mid-range because the length comes at the cost of usefulness.

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 0% parameter coverage and total absence of routing guidance leave the agent under-prepared. For a tool in a dense sibling namespace containing four other approval-related tools, this is insufficient.

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

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

Schema description coverage is 0%, so the description must carry the burden of explaining 'workflowTemplateId', but it says nothing. It does not clarify that the ID comes from 'list_approval_templates', nor does it explain the pattern or length constraints that are already in the schema.

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

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

States a verb and resource ('Read an approval workflow template'), which is clearer than the title alone. However, it does not distinguish this single-template fetch from the sibling tools 'list_approval_templates' or 'get_approval_request', so an agent must infer the difference from the 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?

No guidance on when to use this instead of 'list_approval_templates' (to discover IDs) or 'get_approval_request'. There is no mention of prerequisites, and no statement of what 'reading' returns or how to obtain a valid template ID.

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, so safety is covered. The description adds one genuinely useful behavioral point — that the response contains definitions rather than saved organization data — but says nothing about scope per module or how the response differs across modules.

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

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

Two compact sentences with the resource area front-loaded and the data-vs-definitions caveat immediately after. There is no filler, though the brevity here edges into under-specification rather than efficient precision.

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 read-only profile is covered by annotations. However, for a schema-introspection tool sitting among many schema-adjacent siblings, the description leaves the key question — what exactly this schema is for and when to prefer it — unanswered.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, yet the single required `module` parameter is never mentioned. The phrase "organization app modules" only loosely gestures at it, and the enum values are visible only in the schema with no explanation of how each module changes the returned definition set.

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?

"Inspect create fields for organization app modules" names a resource area but the noun phrase is ambiguous — it is not clear whether it returns a schema of fields used when creating module records, or field definitions themselves. It does not distinguish itself from close siblings such as get_schema, get_module, or get_company_configuration_schema.

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

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

No statement of when to call this versus get_schema, get_module, or get_tool_contract, and no prerequisites or exclusions. The agent must infer usage from the tool 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?

The annotations already declare readOnlyHint, idempotentHint, non-destructive behavior, and a closed-world profile, so the safety burden is largely covered. The description usefully adds that the returned book includes policy and SOP contents, but it does not clarify access requirements, pagination, or failure behavior.

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

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

The description is a single front-loaded sentence with no redundant or wasted language. It communicates the operation and included content 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?

For a simple one-parameter read tool with rich annotations and an output schema, the description covers the core action and returned content. However, it leaves the bookId source and the relationship to list_books and related get_* tools unaddressed, so it is only minimally complete.

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

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

Schema description coverage is 0%, and the single required parameter bookId has no semantic explanation in the description. Calling it 'a book' does not tell an agent how to obtain or interpret the identifier, so the description does not compensate for the missing schema documentation.

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: read a book, and adds that it includes policy and SOP contents. It is clear what the tool does, but it does not explicitly distinguish itself from nearby tools such as list_books, get_policy, or get_sop.

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 'read a book' and the required bookId, but the description gives no explicit guidance on when to use this tool versus list_books, get_policy, or get_sop. It provides context but no alternatives or exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds one non-obvious behavioral fact — the response carries no organization data or secrets — which is useful. It stops short of saying what the contract actually contains or how invalid modules behave.

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 compact sentence with no filler, and the preflight timing is front-loaded. It is efficient to the point of under-specification, but 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?

An output schema exists, so return values needn't be documented. Still, for a tool whose only input is a required four-way enum, the description supplies zero help in picking a module or understanding what each module's contract governs, leaving a real gap in an otherwise simple 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 0%, so the description bears the burden and fails: the required 'module' parameter is never mentioned, nor are the four enum values (settings, document_styles, policy_layout, roles) or how choosing among them changes the result. The enum constrains inputs but the description gives no semantic guidance.

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

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

The verb 'Inspect' and the resource 'configuration contract' gesture at the intent, and the title confirms it returns a schema. But 'configuration contract' is jargon that never resolves into which configuration (settings? roles? policy layout?) the schema covers, and nothing distinguishes it from near-identical siblings like get_schema, get_app_schema, and get_tool_contract.

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?

'Before editing' implies a preflight use case, which is genuine guidance. However, no alternative is named among the several other schema/contract tools in the sibling list, so an agent cannot tell when to prefer this one over get_schema or get_app_schema.

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 behavior, and closed-world scope, so the safety profile is covered. The description adds useful context that these are saved defaults rather than active document formatting, but it does not discuss permissions, rate limits, or empty-state behavior.

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

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

The definition is a single front-loaded sentence with no boilerplate or repetition. Every listed item earns its place by clarifying what style data is returned.

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 getter with rich annotations and an output schema, the description is complete enough. It identifies the exact configuration data being read, and return-value details are left 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 accepts zero parameters, so there are no parameter semantics to document. The empty input schema is consistent with the description, and the baseline for a parameterless tool 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 uses a clear verb, "Read," and names the specific resource: the company's saved default document styles. It enumerates the relevant style attributes (fonts, sizes, colors, paragraph styles), making it easy to distinguish from general company settings or schema tools.

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

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

The description implies that this tool retrieves saved default styles, but it gives no explicit guidance on when to use it versus related tools like get_company_settings or get_company_configuration_schema. There are no exclusions or alternative-selection criteria.

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

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

Annotations already declare read-only, idempotent and non-destructive behavior, so the safety profile is covered. The description earns credit for adding a concrete exclusion list — billing, authentication, credentials and platform configuration are never returned — which prevents an agent from calling it expecting those fields.

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

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

Two short sentences with no filler. The positive scope is front-loaded and the negative scope follows immediately, which is exactly the right ordering for a retrieval tool.

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 shape needn't be described, and annotations cover the safety profile. The description supplies the key missing piece — what data is out of scope — though it could note whether results are company-wide or user/location-scoped.

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 no parameter space the description needs to explain.

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?

Uses a specific verb ('Read') plus an enumerated resource ('company preferences, headers, footers and categories'), which distinguishes it from adjacent siblings like get_company_configuration_schema and get_company_document_styles. It stops short of naming any sibling explicitly, so an agent must infer the boundary from the content 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?

Usage is only implied: the tool is for reading safe preference data. There is no explicit 'use this when…' or guidance on when to prefer get_company_configuration_schema, list_company_integrations or get_company_document_styles instead.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds no behavioral context beyond 'Read' and does not explain scope, freshness, or organizational boundaries.

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

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

The description is a single front-loaded sentence with no filler. It is appropriately terse for a zero-parameter read tool, though the brevity leaves usage context unstated.

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 cover safety, so return values and mutation behavior need not be explained. However, the description does not help an agent choose this scorecard over adjacent compliance tools, which is the main 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?

The tool has zero parameters, so there are no parameter semantics to explain. The baseline for a parameterless tool 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 gives a clear verb and resource: 'Read organization compliance scorecard.' It is understandable on its own, but it does not distinguish this tool from related siblings such as get_compliance_trends, get_location_compliance_gaps, get_risk_heatmap, or get_dashboard.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many compliance-related siblings available, an agent must infer the selection criteria from the tool 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is clear without the description. The description adds the organization-level scope but no further behavioral context such as time ranges, permissions, or aggregation behavior.

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

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

The description is a single front-loaded sentence with no filler or repetition. For a zero-parameter read tool, this is appropriately sized and wastes nothing.

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 the description need not explain return values, and the annotations cover the operational profile. The remaining gap is that 'trends analytics' is not further scoped or related to sibling analytics tools, but overall the definition is complete enough to invoke the tool correctly.

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

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

The tool has zero parameters, so parameter semantics are inherently simple and the baseline for a no-parameter tool is 4. There is no parameter syntax or filtering behavior that the description needs to compensate for.

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 ('Read') and resource ('organization compliance trends analytics'), so the basic operation is clear. However, it does not distinguish this tool from similarly named siblings such as get_compliance_scorecard, get_risk_heatmap, or get_adoption_rates.

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 alternatives. With many adjacent compliance-analytics siblings, the description should explain whether this is for trend-over-time analysis, executive reporting, or something else, but it says only what the tool reads.

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

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

The annotation suite (readOnlyHint: true, destructiveHint: false) already provides strong behavioral guarantees. The description adds minimal value by confirming it is a 'Read' operation, which is redundant but confirms the non-mutating nature of the tool.

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

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

The tool definition is highly concise. The single sentence is direct, efficient, and contains zero unnecessary words, maximizing the information density.

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

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

Given the simplicity of the schema (one ID), the description provides just enough information to identify the tool's function. However, since it has 0% parameter description coverage, the description lacks any deeper explanatory context about the required input.

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

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

Schema description coverage is 0%, requiring the description to add semantic value. However, it merely identifies the resource ('contact') but fails to provide context on the required parameter ('contactId') beyond its role in accessing the configuration.

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 specific language—'Read a contact's site/category access configuration'—which immediately identifies the resource and the exact type of configuration being retrieved. It distinguishes itself well from generic list or export tools in the sibling set by focusing on a specific access setting.

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

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

The description provides no guidance on when to use this tool versus alternatives. It makes no mention of prerequisites or scenarios where another tool in the large sibling list would be more appropriate for the user's goal.

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 the safety profile is clear. The description adds no behavioral context beyond the operation type; it does not mention aggregation, time range, rate limits, or any other trait that would help the agent understand the tool's behavior in depth.

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

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

The description is a single, front-loaded sentence with no wasted words. It directly states the tool's purpose without unnecessary elaboration.

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

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

Given the low complexity (no parameters, read-only) and the presence of an output schema, the description is minimally adequate. However, it remains vague about what 'dashboard metrics' actually includes, which could hinder an agent's decision to use this tool over more specific metric-oriented 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?

The tool has zero parameters, so the baseline score of 4 applies. The schema is empty and the description does not need to explain parameters.

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

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

The description states a specific verb (Read) and resource (organization dashboard metrics), making the operation clear. However, it does not differentiate from the many sibling tools that return specific metrics (e.g., get_compliance_scorecard, get_adoption_rates), leaving ambiguity about what 'dashboard metrics' encompasses.

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

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

The description provides no guidance on when to use this tool versus alternatives. It lacks any indication of context, prerequisites, or comparative use cases, leaving the agent to guess its place among the numerous get_* 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 profile is fully covered by structured data. The description contributes nothing beyond that – no note on what the template contains, whether it is a stock or custom template, or any access constraints – so there is no added behavioral value.

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

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

It is a single front-loaded sentence with zero waste, but the brevity comes at the cost of under-specification rather than efficiency; there is room for one clause on sourcing templateId or the list/get relationship.

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 (one param, output schema present so return values need not be described), but with 0% schema coverage the description should at least say what templateId identifies and how to obtain it. Nothing an agent needs to invoke this correctly is stated.

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

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

Schema description coverage is 0% and the single templateId parameter carries only a regex pattern and length bounds, with no prose description. The tool description never mentions templateId or where a valid value comes from, so it does not compensate for the schema gap.

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

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

"Read a PDF export template" names a verb and resource, and the singular phrasing plus required templateId implies a single-record fetch rather than a listing. However it never distinguishes itself from list_export_templates (the obvious way to discover a templateId) or from the many export_* tools in the sibling set.

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 call this versus list_export_templates, nor any prerequisite such as 'templateId comes from list_export_templates'. The agent must infer the workflow entirely.

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 a closed-world profile, so the safety behavior is fully covered elsewhere. The description adds nothing beyond that — no note on error behavior for missing IDs, no visibility/permission constraints, and no hint about what a Law Watch event contains.

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

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

The description is a single front-loaded sentence with zero waste, which is structurally sound. But its brevity is under-specification rather than efficiency — there is room for one more sentence that would materially help selection.

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 explanation is not required, and annotations cover the safety profile. What remains missing for a required-ID lookup tool is how to source the ID and how this differs from list_law_events, leaving the definition thin for its complexity.

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

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

Schema description coverage is 0% and the single parameter lawEventId has no description, pattern rationale, or origin explained anywhere. The description does not say where to obtain a law event ID (e.g., from list_law_events), which is the main ambiguity for a by-ID lookup 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?

The sentence pairs a verb ("Read") with a resource ("Law Watch event"), so the basic operation is identifiable. However, "Law Watch event" is domain jargon that the description never grounds, and it does not distinguish this retrieval-by-id tool from the sibling list_law_events beyond the singular noun.

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 versus list_law_events, no statement that a valid lawEventId is required, and no indication of what to do if the ID is unknown. The agent must infer everything from the singular/plural tool names.

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 fully covered and the description carries a light burden. The only added context is the tenancy scope ("in this organization"), which is genuinely useful for knowing the ID is org-local. Nothing is said about not-found or invalid-ID behavior, so it is adequate but not rich.

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

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

One front-loaded sentence with zero filler, appropriately sized for a single-parameter read. It is efficient, though the brevity borders on under-specification rather than polished concision.

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 the safety profile. However, for a lookup tool the description never clarifies what a "site/location" entity is or how to obtain the required ID, leaving a real gap for an agent that has no ID in hand.

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

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

Schema description coverage is 0%: locationId has a pattern and length bounds but no documented meaning, and the description only alludes to "a specific site" without explaining where the ID comes from or its format. For a single required identifier, the description should compensate and does not.

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 ("Read") and resource ("a specific site"), making clear this is a single-item fetch rather than a listing. It does not name the sibling that handles the alternative case (list_locations / find_locations_by_field), and it swaps "site" for "location", which is a minor terminology drift from the 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?

There is no guidance on when to use this versus list_locations or find_locations_by_field, and no prerequisites such as needing a valid locationId. An agent must infer the routing from the verb 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 establish that this is a read-only, idempotent, non-destructive, closed-world operation. The description adds no behavioral context beyond the annotations and largely restates the title, saying only that it reads a site scoped summary.

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

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

The description is a single front-loaded sentence with no wasted words. It is concise, but the brevity reflects under-specification rather than a fully complete 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?

The tool is simple, the output schema exists, and annotations cover safety, so the definition is minimally sufficient for invocation. However, it does not resolve ambiguity with similarly named acknowledgement summary siblings, which is the main remaining context gap.

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

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

Schema coverage is 0%, so the description should clarify the single locationId parameter, but it only implies a site identifier. It does not explain identifier format or constraints, leaving the schema's regex and length limits as the only parameter documentation.

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: read an acknowledgement summary, scoped to a site. This distinguishes the location-level tool from company-level siblings such as get_acknowledgement_summary, though it does not explicitly name or compare against those alternatives.

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 get_acknowledgement_summary, get_acknowledgment_overview, get_acknowledgement_tracking, or location compliance tools. The reader must infer the intended use case from the tool name and phrase 'site's'.

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, closed-world, and non-destructive, so the safety profile is covered. The only added signal is the word 'saved', hinting at a stored snapshot rather than live computation, but nothing is said about freshness, size, or behavior when no gaps exist.

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 the resource and scope front-loaded and zero filler. It is appropriately sized, though brevity here edges toward under-specification rather than precision.

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, but with an undocumented required parameter, no usage guidance, and no disambiguation from get_compliance_scorecard/get_compliance_trends, the definition is not complete enough for confident invocation.

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

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

Schema coverage is 0% – locationId has type and pattern constraints but no description. The description does not say what a location id is, where to obtain it (e.g., list_locations), or whether an unknown id errors or returns empty, so it fails to compensate for the coverage gap.

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

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

States a specific verb ('Read') and resource ('compliance gaps') scoped to a site, but 'saved' is unexplained and there is no differentiation from near-siblings such as get_compliance_scorecard or get_compliance_trends, which an agent could easily confuse with it.

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

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

No statement of when to use this tool, when to prefer an alternative, or what prerequisite (a valid location id) is needed. The agent must infer everything 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 declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds that the tool returns definitions and available options, but does not disclose error behavior, missing-module handling, or permission requirements; with rich annotations, this is adequate but not strong.

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

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

The description is a single front-loaded sentence with no filler or repetition. Every word contributes to identifying the tool's scope.

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 annotations cover safety. However, the lone input parameter is unexplained, there is no guidance on retrieving a valid moduleId, and usage versus list_modules is left implicit, leaving gaps for a simple read tool.

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

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

There is one required parameter, moduleId, but the schema description coverage is 0%, so the description must compensate and does not. It never mentions moduleId, its format, or where to obtain it, leaving the only parameter undocumented in both structured and natural-language fields.

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

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

The description states a clear verb (read) and resource (a field module's definitions and available options), which distinguishes it from the sibling list_modules at a high level. It does not explicitly name list_modules as the broader alternative, but the singular scope is inferred from the wording.

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 this is the tool to call when it needs a single module's definitions and options. There is no explicit when-to-use guidance, no mention of when to prefer list_modules, and no prerequisites or source for moduleId.

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 state readOnly, idempotent, closed-world and non-destructive, so safety is covered. The description contributes nothing further: no mention of the error case for an unknown ID, no hint that the caller must obtain the ID from the list endpoint.

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

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

It is short and front-loaded, but the brevity comes from omission rather than efficiency — a single four-word sentence that would need at least one clarifying clause to be useful.

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?

Output schema exists so return values need not be described, but for a lookup tool the description should still say the ID originates from list_notification_rules and that a single rule is returned. Neither is present, so the definition is under-specified for its complexity level.

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

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

Schema description coverage is 0%: notificationRuleId is documented only by a pattern and length bounds, with no statement of what it identifies. The description does not compensate in any way, leaving the sole required parameter semantically unexplained.

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

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

"Read a notification rule" only restates the tool name (get = read) plus the resource. It never says this retrieves a single rule by identifier, which is the one fact that distinguishes it from the sibling list_notification_rules.

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

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

No guidance at all on when to call this versus list_notification_rules or any of the other get_* tools. The agent must infer from the name that an ID is required first.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful organizational scope, but does not mention permission requirements, not-found behavior, or any other operational caveat beyond what annotations provide.

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

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

The single sentence is front-loaded and free of waste, which suits a simple get-by-id tool. The phrasing 'one policies record' is slightly awkward, but structure and size are otherwise appropriate.

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, annotations cover safety characteristics, and an output schema exists, so the description does not need to explain return values. However, it leaves the required id parameter semantically undefined and gives no routing guidance among related policy 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?

Schema description coverage is 0%, so the description needs to compensate for the undocumented id parameter. It does not explain that id is the policy identifier, nor does it add meaning beyond the schema's pattern and length constraints.

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: read one policy record. It also scopes the operation to 'this organization' and distinguishes singular retrieval from listing tools. It does not explicitly contrast with close siblings such as get_policy_workspace or get_policy_assignment.

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 'Read one': use it when retrieving a single policy. The description gives no explicit guidance on when to use this instead of list_policies, get_policy_workspace, or export_policy_pdf.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description confirms a read operation but adds no additional behavioral context beyond the annotations, and it does not contradict them.

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

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

The description is a single front-loaded sentence with no wasted words. Its extreme brevity is efficient, though it leaves other important details unstated.

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

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

This is a simple get-by-ID operation, an output schema exists, and annotations cover safety, so the description is minimally sufficient. It still omits parameter semantics and any routing guidance versus list_policy_assignments or related get 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 has one required parameter, assignmentId, but schema description coverage is 0% and the description never mentions the parameter or its expected format. The agent must infer the ID requirement and pattern constraints solely from the schema.

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

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

The description states a clear verb ("Read") and resource ("policy-assignment rule"), so the basic purpose is understandable. However, it does not distinguish this get-by-ID tool from siblings such as list_policy_assignments, get_policy, or get_policy_workspace.

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 alternatives. It does not mention list_policy_assignments for listing or explain that the tool requires an assignment ID.

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, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered without the description. The description adds the content scope (layout, shared draft state, suggestions, releases), which is useful, but it does not disclose error behavior for an invalid policyId or access constraints, and much of the content list overlaps with the existing 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 read scope and followed by the timing cue; nothing is padded. The terseness is appropriate even if the density of jargon ('workspace', 'frozen releases') leaves some ambiguity.

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 carry the safety profile, so the description need only cover scope and usage. It does that partially, but leaves the central 'policy workspace' concept and its relationship to get_policy undefined, which is the most likely source of mis-selection among 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?

The description says nothing about policyId, and schema description coverage is 0%, so no compensation for the gap occurs. Mitigating factor: there is exactly one parameter and its name is nearly self-documenting in the context of a policy tool, so the practical harm is limited rather than severe.

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') applied to a composite resource and enumerates its parts: policy layout, shared draft state, tracked suggestions, frozen releases. That is more informative than a tautology. However, it never differentiates the 'workspace' from the sibling get_policy or list_policy_comments, so an agent cannot fully tell whether this supersedes or complements those tools.

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

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

The second sentence, 'Use before document workspace changes', gives a genuine timing cue that implies this is a read-prerequisite for mutation. But it offers no when-not guidance, no named alternatives, and no prerequisites (permissions, whether the policy must be in a draft state).

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

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

The annotations already establish that this is read-only, idempotent, non-destructive, and closed-world. The description adds only an organization-level scope word and does not disclose any additional behavioral context such as permissions, pagination, alert freshness, or result shape.

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

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

It is a single front-loaded sentence with no wasted clauses. It is appropriately short, though the phrase "predictive alerts analytics" is slightly awkward and under-specified.

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 zero parameters, much of the contract is already covered by structured fields. Still, the description does not clarify the alert domain or usage context, leaving the agent with only a minimal organizational scope.

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

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

The tool has zero parameters, so there are no parameter semantics to explain. The baseline for zero-parameter tools applies, and the description need not compensate for undocumented 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 read operation on organization predictive alerts analytics, which is more than a bare restatement but still vague about what the analytics represent. It does not distinguish this tool from sibling analytics tools such as get_risk_heatmap, get_compliance_trends, or get_adoption_rates.

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 guidance on when to use this tool versus related analytics or alert tools. The description gives no prerequisites, exclusions, or sibling routing.

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

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

The annotations already declare this as a read-only, idempotent, non-destructive operation. The description is consistent with those annotations and adds that the tool reads a 'saved report definition' rather than report results, but it does not describe permissions, errors, or other behavioral details.

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

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

The description is a single front-loaded sentence with no wasted text. For a simple getter, the brevity is appropriate.

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 output schema and annotations reduce what the description must explain, and the tool has only one parameter. However, the description still lacks parameter guidance and sibling differentiation, leaving notable gaps for an agent selecting among many report-related 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 schema has one required parameter, reportId, with pattern and length constraints but 0% description coverage. The description only indirectly implies that reportId identifies a saved report; it does not explain where to obtain the ID or add meaningful semantics beyond the schema.

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

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

The description states a specific verb and resource: 'Read a saved report definition.' This is clearer than the title alone, but it does not explicitly distinguish the tool from siblings such as list_reports, preview_report, or export_report.

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 no explicit guidance on when to use this tool versus list_reports, preview_report, export_report, or other report-related siblings. Usage is only implied by the need to retrieve a saved report definition by ID.

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, so the safety profile is fully covered structurally. The description adds nothing beyond that — no statement about what the returned columns include (names, types, labels) or why entity selection changes the result set.

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 filler, and the verb-resource pair leads. It is arguably too terse for the ambiguity it leaves, but there is zero wasted text.

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. Still, for a 0%-covered enum parameter in a crowded sibling set, the description should say what 'entity' selects and how this differs from related report tools; it does not.

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

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

Schema description coverage is 0% and there is exactly one parameter, 'entity', with an enum of ten values and a default of 'location'. The description only echoes the word 'entity' without explaining that it selects which report data type's columns are returned, leaving the agent to reverse-engineer the enum values.

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 ('Discover') and resource ('report columns') scoped by entity, which is more than a restatement of the title. However, it does not distinguish this from nearby siblings like get_report, list_reports, or get_report_filter_operators, so an agent must 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?

Usage is only implied: an agent can deduce this is a discovery/introspection call that precedes building or exporting a report. There is no explicit when-to-use, no mention of alternatives such as preview_report, and no note that this is a prerequisite step.

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 tool is read-only, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds the field-type scoping context but does not disclose edge cases, accepted field types, or any behavior beyond the core purpose.

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

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

The description is a single front-loaded sentence with no wasted wording. It is appropriately sized for a simple discovery tool.

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 do not need to be explained, and annotations cover safety. Still, for a tool whose only parameter has no schema description, the description should do more to clarify valid fieldType inputs.

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

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

Schema description coverage is 0%, so the description must compensate for the single fieldType parameter. It says the operators are for a field type, but it does not explain accepted values, casing, format, or the default of TEXT, leaving key parameter semantics undocumented.

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: 'Discover supported report filter operators' for a field type. It is clear what the tool returns, though it does not explicitly distinguish itself from nearby report-related siblings such as get_report_columns.

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: use it to find supported operators for a given field type. However, there is no explicit when-to-use guidance, no exclusions, and no named alternatives among the report-related sibling tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only the word 'metadata', hinting the payload is descriptive rather than the document content — a small but real contribution. It says nothing about behavior on a missing or unauthorized resourceId, which annotations do not cover.

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?

Four words, zero waste, front-loaded — but the brevity is under-specification rather than economy. It fits on one line yet omits routing and parameter facts an agent needs before the first call.

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 the description need not explain return values, and the annotations cover the safety profile. However, a single-record getter in a family of sixty-plus get_* siblings needs at least a pointer to the ID source and a contrast with download_resource; both are absent.

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 exactly one parameter, resourceId, and schema description coverage is 0% — the schema supplies only a pattern and length bounds, never what the ID refers to or how to obtain it. The description does not compensate: it never mentions resourceId, its format, or where IDs come from (e.g., list_resources).

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 'Read' and the object 'resource metadata' identify the operation, but the description never distinguishes this from near-identical siblings such as list_resources or download_resource. An agent cannot tell from this text alone whether get_resource returns a single record, a metadata envelope, or the file itself.

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

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

There is no when-to-use statement, no prerequisite, and no named alternative ('use download_resource for the file body'). The agent must infer routing from the tool name and the required resourceId 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?

The annotations already establish that this is a read-only, idempotent, non-destructive, closed-world operation. The description adds only the organizational scope and the name of the artifact, without disclosing data freshness, permission requirements, or any other behavioral context beyond the annotations.

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

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

The description is a single front-loaded sentence with no filler. It is appropriately sized for a zero-parameter retrieval tool.

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, rich annotations, and an output schema, the definition has enough structural context to make the call safely. It is nonetheless incomplete for selection among many analytics and compliance siblings, because it offers no usage context or domain framing for what the risk heatmap represents.

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

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

The tool has zero parameters, so there are no parameter semantics for the description to explain. The baseline for a zero-parameter tool is 4, and nothing in the description misrepresents the input surface.

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 clear verb ('Read') and named resource ('organization risk heatmap analytics'), so an agent can identify the artifact being retrieved. However, it does not distinguish this heatmap from related siblings such as get_dashboard, get_compliance_scorecard, or get_compliance_trends.

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 adjacent analytics or dashboard tools. The description supplies neither use cases nor exclusions, leaving routing entirely to the caller's inference.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), but the description adds real value beyond them: it states availability ('every authenticated connection') and a data-scope guarantee ('contains no organization records'), which tells the agent this is safe to call and returns metadata only. It stops short of describing response shape or whether output is large.

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, each doing distinct work: purpose/trigger first, then access and data-scope reassurance. Nothing 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?

Output schema exists, so return values needn't be spelled out, and annotations cover the safety profile. For a single-enum read-only introspection tool, the description supplies purpose, timing, auth scope, and data sensitivity — the only gap is the sites/locations wording.

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

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

Schema description coverage is 0%, so the description must carry the module parameter. It enumerates the four modules, matching the enum, but uses 'sites' rather than 'locations' and never explains what selecting a module actually returns or how the fields differ per module.

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 ('inspect exact supported input fields') plus the resources covered (sites, policies, SOPs, employees), which lets an agent distinguish it from record-reading tools like get_policy or get_sop. Minor friction: the prose says 'sites' while the enum uses 'locations', so the mapping requires 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?

'before creating or updating records' gives a clear trigger condition, which is genuinely useful usage guidance. It does not name alternatives (e.g. get_app_schema, get_tool_contract, get_company_configuration_schema) that a sibling-heavy server would plausibly require, so the routing is incomplete.

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 fully covered without the description. The one piece of added context is the organizational scoping ("in this organization"), which tells the agent access is tenant-bounded. It says nothing about behavior for missing ids or records outside the org.

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 zero filler and no repetition of structured fields. It is efficient but borders on under-specification rather than deliberately compact, so it falls short of 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?

The tool is a trivial single-parameter read: annotations cover safety and idempotency, an output schema exists so return values need no explanation, and there are no nested objects or enums. The remaining gap — how to obtain the id — is real but small, so this lands at 4-5; scoring 5 given how little the description is obligated to carry.

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

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

Schema description coverage is 0%, so the single required `id` parameter is documented only by a regex pattern and length bounds — nothing explains that it is an SOP identifier or where to source it. The description's phrase "one sops record" hints at the mapping but adds no format, sourcing, or error semantics.

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 a bounded resource ("one sops record"), plus an organizational scope ("in this organization"). It does not name or distinguish itself from adjacent siblings such as list_sops or list_location_sops, so an agent must infer that the singular/plural split is the differentiator.

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 guidance, no mention of how to obtain the required id (e.g., from list_sops), and no statement of when to prefer a sibling. The only cue is the word "one", which implicitly signals a single-record fetch rather than a listing.

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 covered. The description's one added contribution is the visibility constraint, which usefully warns that results are permission-scoped, but it says nothing about error behavior for inaccessible IDs or lookup-failure semantics.

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 zero filler. It is efficiently sized, though the brevity edges into under-specification rather than maximal density of useful 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 annotations cover safety. What remains missing for a simple lookup tool is any linkage between the required ID parameter and where an agent obtains it, plus lookup- failure expectations.

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

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

The schema has 0% description coverage and the description never mentions supportRequestId — no format hints, no statement that it is the ID returned by list_support_requests. The schema's pattern and length constraints exist, but the description does nothing to compensate for the missing semantic layer.

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 ("support request") and adds a visibility scope ("visible to the connection owner") that distinguishes it from the sibling list_support_requests, which returns collections. It stops short of explicitly naming the sibling, but the singular-resource framing makes the distinction clear.

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

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

There is no statement of when to use this versus list_support_requests, no mention that it requires a known ID, and no guidance on what happens for IDs outside the owner's visibility. The agent must infer usage entirely from the tool 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 readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds nothing beyond that—no note on error behavior for a missing/unknown taskId, no scoping to the caller's company, no indication of what a "document task" actually contains.

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, but it reads as under-specification rather than deliberate brevity—there is room for one clarifying clause about what a task is and how it differs from list_tasks.

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 needn't be explained, and annotations cover safety. But for a tool whose resource concept ("document task") is not defined anywhere else in the definition, the description is too thin to let an agent confidently choose it among dozens of get_*/list_* 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?

Schema coverage is 0%, but the single parameter is taskId, whose meaning is self-evident from the tool name and whose format is constrained by the schema (pattern, 1–128 chars). The description adds no meaning beyond that but also leaves little ambiguity.

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?

"Read a document task" gives a verb and a resource, so the agent knows this is a single-item read. However, "document task" is undefined and nothing distinguishes it from list_tasks or the other get_* siblings, leaving the purpose only partially clear.

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

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

There is no guidance on when to call this versus list_tasks or any related getter, no prerequisites, and no exclusions. 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 confirm the tool is safe and read-only. The description adds value by explicitly scoping the data ('organization'), which is a key piece of contextual behavioral information not covered by the structured hints.

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

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

The definition is highly concise, using a single, direct sentence. There is zero waste in the phrasing, and the statement is immediately front-loaded.

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

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

Since the tool has zero parameters, the primary concern for completeness is the scope of the data, which is clearly defined as 'organization'. With an output schema present, the definition is complete for determining the intent.

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 accepts zero parameters. According to the rules, a tool with no parameters automatically receives a high score for parameter semantics as the description provides no additional context to compensate for schema lack.

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

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

The description clearly states the action ('Read') and the resource ('organization time to acknowledge analytics'). It is specific enough that an agent can place it in the realm of metrics/reporting without complex analysis.

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 definition provides no context on when to use this tool versus alternatives. Given the large set of sibling tools (e.g., get_acknowledgement_summary, get_location_compliance_gaps), an agent lacks guidance on which specific business need this high-level metric satisfies.

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 non-destructive behavior, so the safety profile is covered. The description adds that the response includes permissions, which is genuine context beyond annotations, but says nothing about error behavior when a tool name is invalid or unknown.

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

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

A single front-loaded sentence with no filler; the scope ('available to this connection') and the deliverable (schema + permissions) are both stated 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?

An output schema exists, so return-value detail is not required, and the description names both payload parts (schema and permissions). The only gap is disambiguation from the several other schema-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?

Schema coverage is 0% and the single 'name' parameter is undocumented in the schema. The description implies it is the tool name ('for a tool available to this connection'), which partially compensates, but it never states whether it is case-sensitive or what qualifies as a valid name.

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 ('Inspect the exact JSON input schema and permissions for a tool'), so an agent knows the output is a schema/permission contract rather than data. It doesn't differentiate itself from siblings like get_schema or get_app_schema, which are plausibly adjacent, leaving ambiguity about which one to pick.

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

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

The phrase 'available to this connection' implies scope and preconditions, which is a useful usage cue. However, there is no explicit when-to-use guidance and no mention of get_schema or get_app_schema as alternatives, so the agent must infer the boundary.

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