MCP Analytics

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds only a loose indication of content areas (Answer, Analytics, Custom Analytics) and says nothing about the form, depth, or freshness of the documentation returned beyond what annotations 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?

A single short, front-loaded sentence with no padding. The trailing fragment 'usage.' is a bit clipped and the enumerated parenthetical makes it feel like notes rather than a polished definition, keeping it 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?

For a one-parameter read-only tool the description is minimally adequate, but with no output schema the agent gets no picture of what a documentation response looks like (full page, snippet, links), and the topic vocabulary is only partially covered. It should say more about the return shape.

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

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

With one parameter at 100% schema description coverage, the schema already documents 'topic' with example values (platform, manual, connectors, docs section). The description's parenthetical list adds marginal color but no syntax, format, or fallback behavior beyond the schema, so the baseline of 3 applies.

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

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

The description identifies the resource (platform documentation and info) but uses a noun phrase rather than a specific retrieval verb, and it never distinguishes itself from doc-adjacent siblings such as ask_library, tools_schema, or discover_tools. An agent can guess it returns documentation but not precisely what it returns that those tools don't.

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

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

There is no statement of when to call this versus the many other knowledge/discovery siblings (ask_library, discover_tools, tools_schema, path_resolver). The mention of sub-areas ('how it works', 'usage') hints at scope but gives no selection criteria 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 cover read-only, idempotent, non-destructive behavior. The description adds the user-facing action of handing over the link and guiding the user, which is useful context, but does not describe any further behavior like navigation or redirection 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?

Two short sentences, both informative: one defines scope and examples, the other explains the intended interaction. No filler or repetition.

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

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

For a simple one-parameter tool with a complete enum and safety annotations, the description is sufficient. It conveys when to use it, what it does, and how to deliver the result; no output schema is needed for a link-returning 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 100% and the single parameter has a clear enum with descriptions. The description does not add additional semantic detail beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description clearly states the tool links users to account pages for actions not doable in chat, listing billing, browser upload, and report management as examples. It is a specific verb+resource, though it does not explicitly distinguish itself from siblings like reports_list or reports_view.

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

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

It provides clear when-to-use context: for anything not doable in chat, such as billing or upload. It does not explicitly enumerate exclusions or name alternative tools, but the intended scope is reasonably clear.

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

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

Beyond the annotations, the description discloses meaningful behavior: a new named arrangement is created, nothing is overwritten, and numbers are untouched. This goes beyond the raw annotations and sets accurate expectations for side effects.

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 delivers the action, scope, side-effect guarantees, and a constraint. It is front-loaded and contains no filler.

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

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

For a two-parameter tool with no output schema, the description covers purpose, safety expectations, and the type of accepted instructions. It is slightly light on alternative routing, but not enough to constitute a real 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 schema already documents instructions as 'What to change, in the user's words', and the description reinforces this as 'layout wishes'. It adds the useful constraint that instructions should not involve number changes, but it does not add extra semantics for estimate_id beyond the 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?

The description uses a specific action ('Apply') and a clear resource ('the estimate's page'), and explicitly frames the scope as layout-only via 'layout wishes'. It distinguishes itself from number-changing tools by stating 'no number changes', making its purpose unmistakable.

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

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

The description clearly implies this tool is for layout-oriented user requests and explicitly rules out number changes. It does not name an alternative tool for numeric edits, but the exclusion is enough to guide an agent toward the correct use case.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior, lowering the bar. The description adds meaningful behavioral context by framing the tool as advisory ('help desk') and by disclosing that it is multi-turn, which tells the agent this is a stateful conversation rather than a single-shot API call. It does not detail context handling, but the annotation coverage is 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 concise and front-loaded: it names the role ('AI help desk') before listing three action areas and the multi-turn trait. Every phrase contributes information, with no filler or repetition.

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

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

For a one-parameter conversational tool with rich annotations and no output schema, the description covers the essential behaviors: what the tool helps with and that it is multi-turn. It does not explain how multi-turn context should be supplied in the message, but given the low complexity, this is a minor gap rather than a serious omission.

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

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

Schema description coverage is 100%, so the schema already documents the sole 'message' parameter. The description's references to 'your question' add no new constraints on format, length, or how to include multi-turn context, which keeps this at the baseline score.

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

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

The description identifies an 'AI help desk' and names three concrete functions: choosing an analysis, interpreting results, and fixing errors, plus 'Multi-turn' to signal conversational use. This is a clear functional scope, but it does not explicitly contrast sibling tools such as check_tool_fit or discover_tools, so it lacks full differentiation.

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

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

It provides clear trigger conditions: use when the user needs help deciding which analysis fits, interpreting results, or troubleshooting errors, especially in a multi-turn conversation. It does not state when not to use it or name an alternative tool for direct execution, so it stops short of explicit exclusion 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, establishing that this is a safe read operation. The description adds behavioral context by mentioning it synthesizes an answer and includes citations, which is useful. It does not contradict annotations and provides sufficient transparency for a query 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 description is a single, concise sentence that front-loads the primary action and scope. It includes the key output detail (synthesized answer with citations) without any fluff, making it exceptionally efficient.

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

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

For a tool with one parameter, no output schema, and comprehensive annotations, the description is complete. It explains the purpose, scope, and expected return form. Nothing an agent needs to decide whether to call this tool is missing, especially given the read-only and idempotent hints.

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

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

The schema description coverage is 100%, so the 'question' parameter is fully documented. The tool description does not add extra semantics about the parameter beyond restating that it is a plain-language question. This meets the baseline of 3 but does not elevate it.

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

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

The description states a specific verb ('ask'), a precise resource ('all your delivered analyses'), and the expected output ('synthesized answer with citations back to specific reports'). This clearly distinguishes it from report listing or viewing tools and conveys its Q&A nature.

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

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

The description gives a clear context: it is for asking a question across the entire report library. It implies when to use it but does not explicitly state when not to use it or name alternatives such as 'answer_now' or 'find_precedent'. Since there are many siblings, the lack of explicit exclusions is a minor gap, but the context is sufficiently scoped.

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 genuine behavioral value by disclosing the returned content (stage progress, queue position, rejection reason tied to objective mismatch, ETA, report link), which matters because there is no output schema. It omits auth or rate-limit context, but that is minor for a read-only status check.

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 verb and resource lead, and the returned items are listed compactly. It is dense but every clause carries information.

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

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

For a read-only status tool with annotations covering safety, the description effectively substitutes for the missing output schema by enumerating what is returned. Nothing critical to correct invocation is absent, though a note on the relationship to package_status would complete the picture.

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

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

Schema description coverage is 100% and both parameters (pipeline_id, track_token) are documented with their provenance in the schema, so the baseline is 3. The description mentions neither parameter nor adds format/syntax detail, so it does not exceed 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 ('Check') and resource ('a commissioned build') and enumerates what it surfaces: stage progress, queue position, rejection reason, ETA, report link. An agent can distinguish it from modify_analysis (which commissions builds), but the description never contrasts it with the similarly-named package_status sibling.

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

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

'Check a commissioned build' implies the tool is used after a build has been commissioned, and the schema ties pipeline_id back to modify_analysis, so the post-commissioning context is inferable. However, no explicit when-to-use trigger or when-not/alternative guidance is stated in the description itself.

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 read-only and idempotent behavior, and the description adds that the result includes a fit verdict, column mapping, and missing-input identification. However, phrases like 'the places it delivers' are vague, and there is no disclosure of how the fit verdict is reached or what happens with invalid inputs.

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 short and front-loads the core question before listing outputs. The telegraphic output list and the unclear 'places it delivers' prevent a perfect structure 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?

With no output schema and three under-described parameters, the description supplies the gist and output categories but lacks clear return-value details and parameter definitions. An agent could probably call it successfully, but not with complete confidence in what it will get back.

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 define the parameters, but it never names objective, tool_name, or dataset_ref directly. It loosely hints at 'library tool' and 'THIS dataset/THIS question', but leaves objective unexplained and the parameter mapping implicit.

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 communicates that the tool evaluates whether a library tool fits a specific dataset and question, and it names concrete outputs (column mapping, missing required inputs, method-fit verdict). It is more informative than the tool name alone, though it does not explicitly contrast itself with sibling tools such as discover_tools or tools_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?

'Before naming a library tool' is an explicit workflow cue, and 'THIS dataset for THIS question' scopes when the tool applies. It gives no when-not-to-use guidance or named alternatives, so it does not fully reach explicit 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?

Annotations already cover read-only, idempotent, closed-world, non-destructive, so the description is free to add the parts annotations cannot: fuzzy matching behavior, the usable ref formats (full uuid:// or bare id), and the important note that `dataset_key` may be null for the platform sample. That null-handling caveat is exactly the kind of context that prevents misinterpretation. It doesn't cover pagination/truncation behavior when `limit` is hit.

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

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

Three sentences, front-loaded with purpose before the chaining detail. The uuid:///dataset_key sentences are dense but each carries operational value for constructing dataset_ref; 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?

With no output schema, the description steps in to describe the returned reference field and its null edge case, and with only 2 fully-documented params plus safety annotations there is nothing else an agent needs to call this correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds 'fuzzy matching' semantics for `search` that the schema's 'Search by name, description, or tags' does not convey. `limit` gets no additional treatment, hence not a 5.

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 ('List and search') and resource ('your uploaded datasets'), plus the matching semantics (fuzzy on name, description, tags). This cleanly distinguishes it from datasets_upload and from the path_* consumers it feeds.

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?

Explains what to do with the result — use the `usage` field (uuid:// reference) as dataset_ref in path_resolver and path_tool_run — which gives concrete downstream usage context. It stops short of explicit when-not-to-use guidance or naming an alternative listing tool.

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

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

Annotations mark this as a write (readOnlyHint=false) that is neither idempotent nor destructive, so safety basics are covered. The description adds real context beyond that: REFRESH overwrites the existing dataset in place, downstream schedules/tools pick up new data on next run, and the upload-link path yields a file only the user can reach.

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

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

Three sentences, front-loaded with the core action and organized by mode. Slightly informal phrasing ('Get your data in') costs nothing in clarity and every clause carries load.

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

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

With no output schema, the description correctly notes what you get back (a dataset_ref ready for path_resolver) and covers both modes plus the in-place refresh lifecycle. Complete for a 3-parameter, zero-required 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 100%, so the baseline is 3, but the description adds the crucial interrelationship: `replace_ref` must be combined with `data` to trigger refresh, and omitting `data` switches to upload-link mode. That pairing semantics is not obvious from the schema alone.

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

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

States a specific verb+resource ('Get your data in' → create the dataset / get an upload link) and distinguishes two operating modes clearly. It lacks explicit differentiation from sibling datasets_list, but an agent can tell this is the write-side counterpart to listing.

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

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

It explicitly routes usage by parameter: pass `data` to create immediately, omit it for an upload link, and add `replace_ref` with `data` to refresh. The when-to-use condition for each mode is spelled out rather than inferred.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely useful behavior the annotations cannot: results are tagged source:'own' or 'standard_library' and ordering puts your own results first. It stops short of describing result volume or pagination, so not a 5.

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

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

Three compact sentences, each load-bearing: what it searches, how matching and default listing work, and the escape hatch. No repetition of the tool name or filler.

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

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

For a one-optional-parameter, read-only discovery tool with no output schema, the description covers sources, matching semantics, ordering, and the fallback route. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema coverage is 100% and the single parameter is self-documenting, so baseline is 3. The description still adds meaning beyond the schema: matching is plain-language (not keyword/exact) and the default ordering when the query is omitted is 'your own first', which the schema does not state.

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 (browse) and resource (analyses you can run), and goes further by naming the two content sources it spans: your commissioned analyses plus the platform Standard Library. An agent can tell this apart from siblings like ask_library, tools_schema, or my_objects 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 explicit when-to-use (browse available analyses), what happens with no argument ('no query lists everything, your own first'), and a concrete fallback path when nothing matches ('Commission it with path_resolver'). Both the trigger and the alternative are stated rather than inferred.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description reinforces this with 'read-only.' It adds useful scope information—'platform-wide' and the kind of results included—but does not disclose result size, ordering, or failure behavior. With annotations covering the main safety profile, this is acceptable 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?

The description is compact and front-loaded with the key usage cue, 'Before estimating.' Both sentences contribute meaningful scope information, and there is no obvious filler or redundancy beyond what annotations already state.

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 three-parameter read-only tool with no output schema, the description leaves 'k' undefined and does not tell the agent what result shape to expect. It orients the agent on why to call the tool but not enough to confidently set all parameter values.

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 three parameters. It loosely maps to 'objective' and 'dataset_ref' via 'how did we answer this objective before, on this data or any data?', but it says nothing about 'k', its default, or how these parameters affect the search. This is minimal added meaning over the raw schema.

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

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

The description clearly states the tool's purpose: to find how a given objective was answered before, by searching prior packages and library runs. It names the resource and scope (platform-wide, read-only) and is clearly distinct in spirit from estimation/execution siblings, though it does not explicitly name a differentiating sibling.

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

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

The phrase 'Before estimating' gives a clear contextual trigger for when to use the tool. However, it does not explicitly state when not to use it or mention alternatives such as discover_tools or run_analysis, leaving the routing partially to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about the data scope (owned objects, grouping by objective), which is useful. However, it does not disclose the behavior of parameters like limit, query, or include_dropped, nor any pagination or filtering semantics. Since annotations cover the core safety aspects, a 3 is appropriate.

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, concise sentence that front-loads the action and resource. It avoids fluff and communicates the core purpose efficiently. It earns a 4 for being well-structured, though it could add a bit more detail without becoming 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?

The tool has three parameters, no output schema, and zero schema description coverage. The description explains the tool's scope but omits parameter semantics and output format. For a list/search tool, an agent needs to know how to use query, what limit does, and what 'include_dropped' affects. The description is incomplete for effective 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 must compensate by explaining the parameters. It does not mention limit, query, or include_dropped at all. An agent has no guidance on what 'query' searches, how limit affects results, or what 'include_dropped' means. This is a critical 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 clearly states the verb ('List and search'), the resource ('objects you own'), and adds specific context (curated charts/tables/figures, grouped by objective). This differentiates it from sibling tools like reports_list or datasets_list, which focus on different resources. The purpose is unambiguous and not a tautology.

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 explains what the tool does and its scope, allowing an agent to infer when it is appropriate. However, it does not explicitly state when to use this tool over alternatives, nor does it mention exclusions or prerequisites. Given the large sibling list, explicit guidance would improve selection accuracy.

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 useful behavioral context by specifying the return contents (status, runs, report link), but it does not disclose details like whether the report link is only present after delivery or how status values are represented. This is acceptable given 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, compact sentence that front-loads the action ('Read an analytics package back') and then lists the key return elements. Every word earns its place, and there is no redundancy with the schema or annotations.

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

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

For a simple read tool with one parameter, strong safety annotations, and no output schema, the description covers the essential return values. It could be slightly more explicit about the package_id parameter mapping, but the overall context is sufficient for an agent to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate for the single parameter package_id. The description names the resource ('an analytics package') but does not explicitly state that package_id identifies which package to read. However, with only one required parameter and a clear resource name, the meaning is easily inferred. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Read') and resource ('an analytics package'), and clearly enumerates what is returned: status, every run under it, and the report link once delivered. This distinguishes it from siblings like rerun_package (which mutates) and build_status (which likely reports a different build/package status).

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

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

The description implies a read-only status-checking use case, and the readOnlyHint/idempotentHint annotations reinforce that it is safe to call for checking package status. It does not explicitly name alternatives or exclusions, but the context of siblings like rerun_package and order_analytics_package makes the intended use reasonably clear.

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

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

The description adds meaningful behavior beyond annotations: it discloses that results are computed on every row, returned in this response, and that the tool abstains rather than guessing when the question is not a read. It does not cover permissions, failure modes, or output shape, but the abstention and scope disclosure are valuable.

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

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

The description is three tight sentences with zero waste, front-loading what the tool computes before the abstention behavior and the timing reference.

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

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

For a read-only aggregate tool with no output schema, the description covers what is computed, the abstention path, and when it applies. It could more explicitly explain the prerequisite relationship with path_resolver and what the returned answer contains, but nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema already documents objective, dataset_ref, and resolution_id. The description adds only indirect context via the path_resolver timing note; the baseline of 3 applies when the schema carries the 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 operation (a read of the data) with concrete examples (total, average, count, top group) and scope (computed on every row, in this response). It does not clearly differentiate from siblings such as path_resolver, path_bespoke, or path_estimate beyond a passing timing reference.

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 through the abstention note: when the question is not a read, the tool says so and names the next step. However, it does not explicitly state when to use this tool versus path_resolver or path_estimate, leaving the caller to infer the workflow.

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

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

The description states 'a retry returns the first order', i.e., repeated calls with the same arguments have no additional effect, while the annotation declares idempotentHint=false. That is a direct conflict on the idempotency dimension, and the same replay claim is repeated in the schema description, so the structured hints and the prose point an agent in opposite directions about retry safety.

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

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

Three short sentences, zero filler, with the action and the required preconditions front-loaded before the retry and timing notes. Every clause carries information an agent needs.

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

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

For a paid mutation with no output schema, the description covers the essentials an agent needs before calling: required confirmation, idempotency key, optional companion tools, and where timing comes from. It is slightly thin on the two undocumented parameters (resolution_id, layout_objective) for a 5-parameter 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 only 40%, so the description must compensate. It adds real meaning for estimate_id ('from a confirmed estimate') and idempotency_key (retry/dedupe purpose, which the schema leaves undocumented), and gestures at tool_names ('library tools alongside'), but says nothing about resolution_id or layout_objective, leaving two parameters unexplained 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 — 'Order a custom analysis built for this data' — and scopes it to a 'confirmed estimate', which separates it from the upstream estimation siblings (path_estimate, review_estimate) and from re-run/reuse siblings. The optional 'library tools alongside' qualifier maps cleanly to the tool_names parameter.

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 two concrete prerequisites: the estimate must be CONFIRMED and 'the person's yes' (human approval) is required, plus a cross-reference for cost/timing ('Time: as path_resolver quotes'). It does not explicitly name when to prefer a sibling (e.g., path_rerun for an existing build) or state exclusions, so it stops short of a 5.

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

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

Annotations already declare non-read-only, non-destructive, non-idempotent and closed-world. The description adds real context beyond that: the result is sampled/approximate, it includes a full-report layout, and it is a confirmation step rather than an order. It does not say what persistent side effect justifies readOnlyHint=false, nor anything about cost or repeat-call 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?

Two short sentences, front-loaded with what is produced; no filler. It is arguably under-specified rather than verbose, but nothing in it is wasted.

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?

Six parameters, 50% schema coverage, no output schema, and a non-read-only tool with unanswered questions (what gets persisted, what the sampled answer looks like, how completeness and layout_objective change the result). For this complexity the description is too thin to let an agent call it confidently.

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

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

Schema coverage is only 50%: tool_names, completeness and layout_objective have no schema descriptions, and the description supplies no meaning for any of them. Apart from echoing that timing comes from path_resolver (already stated in resolution_id's schema text), it adds nothing about how to populate the six 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?

Conveys that this produces a sampled/rough preview answer plus a report layout for confirmation, which is more than a restatement of the name. However, it never states a clean verb+resource and doesn't distinguish itself from near-identical siblings like adjust_estimate, review_estimate, or path_answer.

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 'for the person to confirm before anything is ordered' implies the right moment to call it (a pre-commitment preview), and the time reference points at path_resolver. But it gives no explicit when-not and does not route the agent to or away from adjust_estimate/review_estimate, which are the obvious alternatives.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the agent knows this executes something non-idempotent without destroying data. The description usefully adds 'no rebuild' and that duration is quoted by path_resolver, but is silent on side effects of a rerun (new outputs? overwrites?) and on permissions.

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 zero filler; the core behavior and the 'no rebuild' constraint are front-loaded, and the timing note is a useful trailing pointer.

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?

Adequate for a 3-parameter execution tool with no output schema, but it leaves the outcome of a rerun and any permission or side-effect requirements unstated. The reference to path_resolver for duration partially compensates.

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

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

Schema coverage is 67%; dataset_ref and resolution_id are already documented in-schema (including the referenced path_input), while package_id is undocumented. The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb+resource: 'Run a delivered analysis again' with the key qualifier 'same tools and mappings, no rebuild.' This distinguishes it from path_bespoke (which presumably builds something new), though it does not name that sibling explicitly.

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

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

Implies when it applies via 'on its own dataset or a new one' and points to path_resolver for timing, but never states when to choose this over path_reuse, path_bespoke, or path_tool_run. Usage is inferred rather than specified.

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), so the bar is lower; the description still adds billing semantics ('charges nothing') and, importantly, discloses the return payload — reason, per-path score and time, and the ready input for the chosen path — which is needed since no output schema exists.

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

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

A single dense sentence, but it is front-loaded with the core action and closes with the two most decision-relevant facts (no execution, no charge). Every clause earns its place, though the parenthetical path list makes it read as a 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?

With no output schema, the description correctly takes on the burden of describing the return shape (reason, scores, timing, ready input). Combined with 75% parameter documentation and annotations covering the safety profile, an agent has nearly everything needed; only explicit when-to-use routing against the path_* siblings is missing.

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

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

Schema coverage is 75% with door, meta, objective and dataset_ref all carrying schema-level documentation, so the structured fields do most of the work. The description text adds nothing about parameter semantics (e.g. what 'door' values mean or what dataset_ref null implies beyond the schema note), so the baseline 3 applies.

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

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

States a specific function: deciding which of eight named paths (reuse, rerun, answer, tool_run, estimate, bespoke, ask, none) a data question should take. The listed outcomes map directly onto the sibling tools (path_reuse, path_rerun, etc.), and 'Executes nothing' makes clear this is the router rather than an executor, so an agent can separate it from those siblings.

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

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

Usage is only implied: the phrase 'Executes nothing and charges nothing' signals a cheap triage step to run before committing to a path, but the description never says when to call this versus calling path_reuse/path_rerun directly, nor what conditions favour it. Adequate inference, no explicit routing 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?

The annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile needs no restating. The description adds the timing link to path_resolver, and the schema text adds genuinely useful behavior (a deleted or non-owned report is refused, re-checked at execution), but that guarantee lives in the schema rather than the main description.

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

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

Two short sentences with the core action front-loaded and no padding. The trailing 'Time: as path_resolver quotes' is terse to the point of being cryptic, which costs a point.

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 annotations covering safety and a fully documented schema, the essentials are covered, and no output schema means return values need not be explained. What remains thin is routing guidance against the crowded path_* sibling set and any indication of what a refusal looks like to the caller.

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

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

Schema coverage is 100%, so all three parameters are already documented, and the description's 'this question on this data' maps loosely to objective and dataset_ref. It adds no meaning beyond the schema for resolution_id, so the baseline of 3 applies.

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

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

The verb-and-resource pair is concrete: it hands back a previously delivered report for a given question on given data, which reads distinctly from generating a new answer. It references 'path_resolver' in the timing clause, implying it is downstream of that sibling's suggestion, but it does not explicitly contrast itself with path_answer, path_rerun, or path_bespoke.

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 phrase 'already delivered' plus the reference to path_resolver's quote suggests it applies when a prior report exists and has been suggested. There is no explicit statement of when to choose this over path_answer or path_rerun, 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 declare this is a non-read-only, non-idempotent, non-destructive write, and the description adds valuable context: it produces charts and a written report, and runtime is quoted by path_resolver (implying a long-running call). It doesn't say whether the run is asynchronous, how results are retrieved afterward, or what happens to prior outputs, so meaningful behavioral gaps remain.

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

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

Three short, front-loaded fragments with no filler; the deliverable and the time expectation come before caveats. The terse 'Time: as path_resolver quotes' is a little clipped but earns its place by warning about an upfront estimate.

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 an 8-parameter, non-idempotent execution tool with no output schema, the description covers the purpose and deliverables but leaves the operational picture thin: no indication of async/polling, cost accounting, or how the returned report and charts are surfaced. Adequate to select the tool, not fully adequate to invoke it confidently.

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

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

Schema coverage is 63%, and the description adds no parameter-level guidance at all. Undocumented in both schema and description are tool_names (where the tool names come from), module_parameters, and estimate_id, and nothing explains how column_mapping interacts with the resolution_id flow.

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 ('Run one or more tested library tools on this dataset') plus the deliverables (charts and a written report), and rules out custom builds. It doesn't name path_bespoke as the alternative, but 'No custom build' signals the boundary clearly enough to distinguish it from the bespoke-path sibling.

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

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

Gives a clear when-to-use context (tested library tools, no custom build) and points at path_resolver as the source of the time quote, which implies the resolution_id prerequisite. It stops short of naming explicit alternatives or stating when re-running / estimate flows should be used 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is covered. The description adds one genuinely new behavioral fact — results render inline in chat rather than as a data payload — but says nothing about pagination, card counts, or card-level filtering.

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; the resource and its clarifying examples come before any other information.

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

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

For a one-parameter, read-only browse tool with no output schema, the description adequately conveys what is fetched and how it is surfaced. It stops just short of noting whether all cards are returned at once or how a large report's cards are delivered.

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 only one parameter and schema description coverage is 100%, with the schema itself noting the id comes from path_tool_run or build_status. The description adds no meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Browse) and resource (a delivered report's individual cards), and the parenthetical '(charts, tables, insights)' concretely defines what a card is. It does not, however, differentiate itself from close siblings such as reports_view or reports_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?

The word 'delivered' hints that a report must already exist, but the description gives no explicit when-to-use guidance, no prerequisite on obtaining a processing_id, and no routing advice versus reports_view/reports_list. Usage is left entirely to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds that results include status and links, giving a bit of output context. It doesn't contradict annotations, but it offers only modest additional behavioral detail 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?

Two compact sentences with no filler. The core purpose is front-loaded, followed immediately by the optional search usage. Every word earns its place, and the structure makes it easy to scan.

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 list tool with no required parameters and no output schema, the description covers the main purpose and the optional search. It omits potential details like pagination or default limit, but those are minor given the tool's simplicity. It is sufficiently complete for an agent to invoke correctly.

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

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

Schema description coverage is 100%: both limit and semantic_query have descriptions. The description re-emphasizes semantic_query but adds nothing about limit or parameter interaction. Baseline of 3 is appropriate since the schema already documents the parameters adequately.

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

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

The description clearly states the tool lists all reports with status and links, using a friendly 'your report library' framing. It also introduces the semantic_query search capability. However, it doesn't explicitly differentiate from siblings like reports_view or report_cards, though the list-oriented purpose is evident.

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 tells when to use semantic_query (for natural-language content search) but gives no guidance on when to use this tool versus alternative report tools. Usage context is implied rather than explicitly stated, and no exclusions or alternative routing are provided.

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 is covered structurally. The description adds a genuinely non-obvious behavioral trait beyond them: the returned link is viewable without authentication, which is security-relevant information an agent cannot get from the annotations. It omits link expiry/persistence, so not a full 5.

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

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

A single front-loaded sentence with zero filler; the verb, the output, and the key constraint all appear 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 read-only tool with full annotation coverage, one documented parameter, and no output schema, the description is nearly sufficient – it states what is returned and the auth posture. Only the lifetime/durability of the generated link is left unstated.

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

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

Only one parameter and schema coverage is 100%, so the baseline is 3. The description adds no meaning about processing_id (source tools are documented in the schema itself), so it neither compensates nor detracts.

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 action and resource: producing a shareable browser link for a report. It is clearly distinct from sibling reports_list (which enumerates reports) and report_cards, though it never explicitly contrasts itself with them.

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 stated outcome (a shareable, no-auth link) implicitly signals when to reach for this tool rather than an authenticated view or reports_list, but there is no explicit when/when-not statement or named alternative. Usage must be inferred from the effect it produces.

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 structurally. The description adds useful content context (a marked sample answer, per-place questions, page link, review checklist), but says nothing about auth needs, pagination, or whether a missing estimate_id errors — modest 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?

It is short and front-loads the core idea, but the embedded list of returned items is crammed into a single run-on sentence, and the trailing 'Before path_bespoke' fragment is telegraphic. Readable but not cleanly structured.

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

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

With no output schema, the description does useful work enumerating what comes back (question as understood, marked sample answer, places, page link, checklist). It leaves the sole input parameter and any error/empty-state behavior unexplained, so it is only partially complete for the tool.

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

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

Schema description coverage is 0% and the single required parameter estimate_id is never mentioned in the description. With one undocumented parameter, the description should carry the burden, but it only alludes to 'the estimate' without explaining the identifier's format or source.

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

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

The description identifies the resource (an estimate) and frames it as the review-oriented view 'as you review it WITH the user,' which loosely separates it from request_estimate and adjust_estimate. However, it is written as a noun phrase describing the payload rather than a clear verb+resource statement of what the tool does, so the action itself is only implied.

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 path_bespoke' supplies a workflow-ordering cue, telling the agent this precedes a later step. There is no statement of when NOT to use it and no comparison against the obvious alternatives (request_estimate, adjust_estimate), so the guidance is implied rather than explicit.

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

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

Annotations already flag destructiveHint=true, so the description does not need to restate that. It adds useful behavioral context beyond the schema: reports are emailed after each run, and create requires a re-runnable reference (connector:// or https://). There is no contradiction between the description and 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 compact sentence with the main purpose front-loaded. It packs a lot of useful information without redundancy, though the parenthetical list is slightly dense.

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

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

The description covers the main actions and some create-specific details, but there is no output schema and no explanation of what 'list' returns or how schedule_id is obtained other than indirectly via the schema. For a multi-action tool with a nested object parameter, this leaves some operational ambiguity.

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

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

With 67% schema description coverage, the schema handles some parameters, and the description adds meaning for action values, cadence (weekly/monthly), and dataset_ref (connector:// or https://). However, tool_name, schedule_id, and especially column_mapping receive no additional explanation in the description, leaving gaps for an agent to infer.

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

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

The description states the resource ('standing re-runs of analyses you own') and the specific verbs/actions ('create', 'list', 'cancel'). It clearly distinguishes this tool from one-off execution tools like run_analysis by emphasizing 'standing re-runs'.

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

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

It clearly implies the tool is for recurring, scheduled re-runs and mentions weekly/monthly cadences, but it never explicitly contrasts with alternatives such as run_analysis or rerun_package, nor states when not to use this tool. The usage context is present but the guidance against/versus alternatives is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds a sequencing dependency, but says nothing about what the returned schema contains or how to interpret it, which is the tool's entire output.

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

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

Two short sentences with the action first and the mandatory sequencing constraint second. Zero filler.

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

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

There is no output schema, and for a tool whose sole job is returning a schema, the description does not hint at the returned structure or how the agent should consume it. The prerequisite note covers workflow but leaves the payoff of the call undescribed.

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

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

Schema description coverage is 100% and the single tool_name parameter is documented in the schema as the analysis name. The description adds no syntax, format, or naming detail beyond that, so the baseline 3 applies.

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

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

States a specific verb (Get) and resource (analysis's parameter schema) with clear scope. It does not explicitly differentiate itself from siblings like discover_tools or check_tool_fit, but the purpose is unambiguous on its own.

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 an explicit imperative prerequisite: 'ALWAYS call before path_tool_run.' That is strong when-to-use guidance. It lacks a when-not clause or named alternative, keeping it below a 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description isn't required to repeat safety traits. It does add a condition: 'Requires warehouse enablement (business plans),' which is useful operational context. However, it doesn't disclose other behaviors like rate limits or error handling, which is a gap given the tool's multi-action nature.

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 sentence, front-loaded with the main verb and resource, followed by a compact list of capabilities and a constraint. There is no filler or repetition. Slightly more organization (e.g., separating capabilities from prerequisites) could make it a 5, but it is already efficient.

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

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

The description gives a solid high-level overview of the tool's purpose and use cases, and it mentions the prerequisite. However, it omits details about the 'params' and 'question' fields, and doesn't explain the distinction between 'query' and 'question'. Given the tool's multiple actions and 4 parameters with no output schema, this leaves the agent partially blind about how to use each action effectively.

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 full responsibility for explaining parameters. It maps some action enum values (catalog→browse, find→semantically find, ask→plain-language ask, queries→named templates) indirectly, but it never clarifies the purpose of 'query', 'params', or 'question'. This partial mapping is insufficient for an agent to construct correct invocations.

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 primary function: 'Query your org's data warehouse free.' It enumerates specific capabilities (browse catalog, semantically find data, plain-language ask, named templates) that distinguish it from generic query tools. However, it does not name any sibling tool or explicitly contrast itself, 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?

The description implies a usage scenario (querying the warehouse) but offers no explicit guidance on when to use this tool vs. alternatives like ask_library or run_analysis. It mentions a requirement (warehouse enablement) but lacks 'use this instead of X' or 'do not use when...' instructions. The agent is left to infer suitability.

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