Numonic

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

No annotations are provided, so the description carries the full burden. It does disclose retrieval scope ("all annotations") and that results contain "author information," but says nothing about permissions, ordering, pagination, or what happens if the node has no 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 no filler; the resource and scope 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?

There is no output schema, and the description only gestures at the return contents ("author information") without describing the annotation structure. For a simple two-parameter read tool it is minimally sufficient, but it leaves the response shape largely unknown.

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

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

Schema description coverage is 100%, so the schema fully documents both workflow_node_id (with pattern) and include_resolved. The description adds no meaning for either parameter, including the non-default include_resolved flag, so baseline 3 applies.

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

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

States a specific verb and resource ("Retrieve all annotations") scoped to "a specific ComfyUI workflow node," which is unambiguous. However, it does not reference any sibling tool or explain how it relates to the other Get* tools in the cluster, so it stops short of a 5.

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

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

There is no guidance on when to call this versus alternatives, no prerequisites, and no exclusions. The usage is only inferable from the phrase "for a specific ComfyUI workflow node."

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?

With no annotations, the description carries the full burden and does so well: it discloses that generation_parameters may be null, that provenance.lineage_source takes 'extracted'/'client_asserted'/'unknown', that asserted_parameters are never merged, and that the download link is valid only 5 minutes. It stops short of explicitly stating side-effect/read-only status or auth requirements beyond the tenant note, so not a full 5 for an annotation-free 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?

Front-loaded with purpose and the return-value map, then organized by field path, which makes it scannable despite its length. It is dense and does repeat some schema content (download-link expiry, curl/fetch), but nearly every clause carries field-level semantics an agent needs given there is no output schema.

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 no annotations, so the description must document the return payload — and it does, enumerating prompts, models[], workflow.workflow_json, generation_parameters, provenance.lineage_source/asserted_parameters, plus title, tags, collections, embedding and copyright. Nothing an agent needs to interpret the response or pick the right sibling is missing.

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

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

Schema description coverage is 100% and each parameter already has a thorough description, so baseline is 3. The description restates rather than adds: the 5-minute link validity and the curl/fetch guidance are already in the schema text for include_download_url, and include_image's rationale largely duplicates its schema 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?

Opens with a specific verb+resource and a precise selector: 'Retrieve comprehensive details for a specific asset by its SHA-1 hash, including how it was made.' It even frames the question it answers ('which prompt, model and workflow produced this?'), which instantly separates it from GetAssetPublicUrl and PublishAsset, and it names GetAssetModels for the adjacent but distinct need.

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?

Explicit routing: 'For Model Library records of those models ... call GetAssetModels' and 'For a URL that does not expire, approve the asset and call PublishAsset.' It also states when to reach for the optional flags (include_image for clients that cannot fetch URLs, include_download_url for a short-lived link), so the agent knows both when to use this tool and when a sibling is better.

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?

With no annotations, the description carries the burden and does disclose meaningful behavior: tenant scoping and the empty-result rule ('an asset your tenant does not hold returns no models'). It does not mention pagination, result limits, or auth beyond tenant binding, but the read-only nature and scope are clear enough for correct invocation.

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 resource and return contents, followed by the scoping constraint and the sibling routing. The parenthetical model-type list is dense but directly useful, and 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?

Although there is no output schema, the description enumerates the returned fields (base model, type, detection source) and the model categories, so the agent knows what to expect. Combined with the tenant semantics and the sibling handoff, nothing needed to call or interpret it 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% for both parameters, so the schema already documents tenant_id's binding/rejection rules and asset_hash's SHA-1 format. The description only implies the asset argument ('a specific asset') and adds no format or syntax detail, 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?

Specific verb+resource ('Get the Model Library records') with an explicit enumeration of the model types returned (checkpoints, UNETs, LoRAs, VAEs, CLIP, upscalers). It clearly distinguishes itself from the sibling GetAssetDetails by stating what that tool covers instead.

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

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

It names an alternative (GetAssetDetails) and the condition that selects it (prompt and ComfyUI workflow graph), which is strong routing. It stops short of covering the other plausible overlapping sibling, GetModelDetails/GetModelVersions, so the when-not guidance 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?

With no annotations to lean on, the description carries the full burden, and it does so well on outputs: it enumerates all three return states and the specific fields (public_url, collection_path, preset, published_at) each yields. It stops short of stating read-only/absence of side effects or any auth/rate-limit behavior, but the state disclosure is genuinely richer than the 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?

Front-loaded with the reverse-lookup framing, then a compact enumerated list of the three states. Every clause maps to a distinct outcome, though the enumeration is dense enough that a slightly tighter phrasing could carry the same 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?

There is no output schema, so the description must explain return values — and it does so exhaustively, covering the published, in-collection-but-unpublished, and uncollected cases with their fields. Nothing an agent needs to call and interpret this tool 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% — asset_h is documented as a SHA-1 40-hex hash and tenant_id as auto-injected from auth — so the schema already carries parameter meaning. The description adds nothing about parameters, which is the correct baseline given full schema coverage.

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 with explicit scope: 'Reverse lookup: finds if an asset is in ANY published collection and returns the public URL.' The 'ANY published collection' phrasing and the 'Reverse lookup' framing distinguish it from the forward sibling GetCollectionPublicUrls, so an agent can route between them without opening either 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?

The three-state breakdown tells the agent what this returns, which implicitly signals when it is useful (checking publication status of a known asset). However, it never names an alternative or states an exclusion — e.g. when to prefer GetAssetDetails or GetCollectionPublicUrls instead. Usage is inferable but not 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?

No annotations are provided, so the description carries the full burden. It usefully discloses the return payload (membership metadata), which is beyond schema, but is silent on auth/permission requirements and pagination behavior (the latter is covered by the schema). For a read tool with zero annotation coverage, this is adequate but thin.

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

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

A single front-loaded sentence with no filler; the resource and the notable return content come first. 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?

For a 6-parameter read tool with no output schema and no annotations, the description is minimal. The schema fully documents inputs, but the description does not fill the gap left by the absent output schema, so an agent gets only a hint of 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?

Schema description coverage is 100%, including detailed notes on tenant_id fallback and the include_nested behavior, so the schema does the heavy lifting. The description adds no parameter-level detail beyond what the schema already states, matching the baseline of 3.

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?

Clear verb ('Get') plus resource ('assets in a collection') and even names the shape of the return ('membership metadata: position, role, added date'). An agent can distinguish it from GetAssetDetails or ListCollections, though it never explicitly contrasts with 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?

No when-to-use guidance, no prerequisites, and no mention of the obvious alternative (ListCollections) or how this differs from GetAssetDetails. The agent must infer the context of use 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?

No annotations are provided, so the description carries the burden. It does disclose the return payload (published flag, publication metadata, per-asset URLs), which is real behavioral content, but it says nothing about permissions, cost, or whether any state changes.

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 front-loaded sentences with zero filler: the first states the action and scope, the second enumerates the return contents. Both sentences earn their place, especially given there is no output schema.

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

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

For a simple two-parameter read tool with a fully documented schema, the description covers purpose and return shape (compensating for the absent output schema). It is slightly thin on authorization/prerequisite context, keeping it out of the top band.

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% for both parameters, so the schema already documents collection_h (SHA-1 format) and the tenant_id credential-binding rule. The description adds no format or constraint detail beyond that, which is the baseline 3 for fully-covered schemas.

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 publication status and public URLs for all assets in a collection') and its scope ('all assets in a collection') distinguishes it from the singular sibling GetAssetPublicUrl. No sibling is named explicitly, 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 scope phrase implies when to use it (collection-wide publication lookup) versus the single-asset sibling, but there is no explicit when-to-use statement, no prerequisites, and no named alternative. Usage is only implied.

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?

With no annotations, the description carries the full burden and does well: it discloses the grouping logic per tool, that each asset reports its time_source, and the notable edge case that 'assets with no tool evidence have no session' (an empty-result condition). It omits auth requirements, rate limits, and any hint at result ordering or size, keeping it short of 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?

The core definition is front-loaded in the first sentence, followed by the per-tool grouping rules that genuinely require the space. No filler sentences; every clause conveys non-obvious domain logic.

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?

No output schema and no annotations, so the description must cover semantics alone, and it explains the return concept richly (grouping windows, time_source). It stops short of describing result shape or the time_window default behavior, but is largely sufficient 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 100%, so both asset_id and time_window are already documented in the schema; the description adds no syntax or meaning beyond it. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb (Discover) and resource (creative session around a given asset), then defines the resource precisely: 'other assets from the same tool made within a time window of it.' An agent can distinguish this from siblings like GetAssetDetails or GetMidjourneyEvolutionChain 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?

Describes what qualifies as a session and the per-tool grouping rules, which implies when the tool applies, but never states when to prefer it over siblings such as GetMidjourneyEvolutionChain or when not to call it. Usage 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose what the result contains (counts and distributions), which is genuinely useful given there is no output schema, but it says nothing about permissions, cost/latency of aggregation, or how missing conditions or empty collections are handled.

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

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

A single front-loaded sentence that leads with the verb and resource, then lists the returned aggregates after a colon. There is no redundant or filler text; every clause adds 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 tool with no output schema, the description usefully enumerates the aggregated values an agent can expect in the response. It stops short of clarifying the meaning of the aggregates (e.g. what a 'condition' or 'comparison count' entails), but nothing essential to calling it 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?

There is a single parameter (collection_h) with 100% schema description coverage, so the schema fully documents the 40-char hex hash requirement. The description adds no meaning beyond the schema for this parameter, which is the correct baseline of 3 when the schema does the work.

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

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

The description pairs a specific verb ('Get') with a clearly scoped resource ('aggregated experiment results') and enumerates the aggregates returned: run count, condition breakdown, outcome tag distribution, comparison count. It does not, however, differentiate itself from similarly named siblings such as GetRelationshipSummary, so an agent still has to reason about which summary tool applies.

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

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

The word 'aggregated' implies this is the tool for high-level experiment statistics rather than raw run data, which is enough to suggest when it fits. But there is no explicit when-to-use statement, no prerequisite guidance, and no named alternative, so usage is only inferred rather than stated.

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

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

With no annotations, the description carries the full burden and delivers a genuinely important behavioral disclosure: steps from another member's private generations surface as placeholder nodes with redacted:true, job_type 'private', and no asset/prompt/command. It even instructs how to describe them. It stops short of covering auth requirements, traversal/recursion behavior, or what normal nodes 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?

Two sentences, front-loaded with purpose followed by the one edge case the agent must not get wrong. Efficient, though the second sentence is dense and the caveat could be split for readability.

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 2-parameter read tool with no output schema and full schema coverage, the description covers the core purpose plus a non-obvious output nuance (redacted placeholder nodes). It is nearly complete; only the general return shape for ordinary nodes is left unspecified.

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 asset_id and max_depth are already fully documented in the schema. The description adds no parameter-level meaning (e.g., how max_depth affects traversal or default behavior), so the baseline 3 applies.

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

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

States a precise verb and resource ('Retrieve the evolution chain (parent→child lineage) for a Midjourney asset') and explains what the chain represents ('how it evolved through variations and upscales'). No sibling tool overlaps, and the domain anchor ('Midjourney asset') makes the scope 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?

Usage is only implied: an agent can infer you call this to understand an asset's lineage, but there is no explicit when-to-use, no prerequisites, and no alternative tool named. The handling note about private steps is a formatting rule, not selection guidance.

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

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

With no annotations, the description carries the full behavioral burden. It discloses what the response contains (metadata, version history, usage and preview counts), which is meaningful for a no-output-schema read tool, but says nothing about permissions, error behavior for an unknown hash, or whether the result is cached/limited.

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 resource and the payload contents are stated immediately and nothing is redundant.

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

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

For a two-parameter read tool with no output schema, the description usefully summarizes the returned fields and the schema covers both parameters in detail. It is only short of the routing/context a sibling-aware agent would want.

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

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

Schema description coverage is 100%, so both parameters (tenant_id with its credential-binding rule and the SHA-1 model_hash) are fully documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get full details for a specific model') and enumerates the payload (metadata, version history, asset usage count, preview count). However, it does not differentiate itself from the sibling GetModelVersions, which the 'version history' phrase arguably overlaps with.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as GetModelVersions. The only implicit signal is that a 'specific model' requires a model_hash, which the schema already enforces.

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?

No annotations are provided, so the description bears the full disclosure burden. It is useful that it enumerates response contents (training steps, quality scores, recommended flag) in the absence of an output schema, but it omits pagination behavior, permission requirements, and any hint that versions can be soft-deleted even though an include_deleted parameter 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 front-loaded sentence with zero filler; the resource and the payoff (which fields you get back) come first. Nothing is redundant with structured fields.

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

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

For a simple two-parameter read tool with full schema coverage, the description covers purpose and return contents adequately. The only real gap is sibling routing guidance and the fact that deleted versions are excluded by default, which the schema already states.

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

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

Schema description coverage is 100%, so both model_hash (SHA-1 pattern) and include_deleted (default false) are already fully documented in the schema. The description adds no extra meaning about either parameter, so baseline 3 applies.

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

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

States a specific verb and resource ('Get version history for a model') and enumerates the returned data points (training steps, quality scores, recommended flag). This clearly separates it from siblings like GetModelDetails and GetAssetModels, though it never explicitly names the boundary between 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?

No statement of when to use this tool versus GetModelDetails or GetAssetModels, and no prerequisites or conditions given. Usage is only inferable from the name, which is weak guidance for a tool with two parameters.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the return contents ('full version history and evaluations'), which is useful and beyond the schema, but it says nothing about permissions, read-only nature, pagination, or side effects. 'Get' implies a safe read, but that is inference rather than disclosure.

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

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

A single sentence, front-loaded with the core action and ending with the payload description. There is no filler or repetition, and every clause contributes to understanding the 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?

This is a simple two-parameter getter with no output schema, and the description usefully names the returned data (version history, evaluations), partially compensating for the missing output schema. It does not mention tenant scoping or competing tools like RenderPrompt, but for a straightforward lookup it is largely sufficient.

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

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

Schema description coverage is 100%, so the schema already documents prompt_h as a 40-char hex hash and tenant_id as a tenant UUID. The description adds no parameter syntax, format, or required/optional nuance beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description gives a precise verb and resource: 'Get a prompt by hash ID.' It also names the returned payload (version history and evaluations), which sharpens the purpose beyond a generic lookup. However, it does not differentiate from the sibling RenderPrompt, which also operates on prompts.

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

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

There is no explicit when-to-use guidance, no exclusions, and no mention of the obvious alternative (RenderPrompt). The only usage signal is the implied read semantics of 'Get,' leaving the agent to infer when this tool is appropriate versus rendering or summarizing a prompt.

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?

With no annotations, the description carries the full burden, and it does substantial work: it discloses the exact metrics returned and the green/amber/red threshold semantics used to interpret them. It stops short of declaring read-only safety explicitly (only implied by 'Retrieve'), and omits auth/tenancy constraints, data freshness, and rate limits, which leaves gaps for a monitoring tool without 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 purpose is front-loaded in the first clause, followed by concrete output contents and thresholds. The parenthetical threshold listing is dense but each detail aids interpretation of the returned health rating, so it earns its space despite the length.

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 no annotations, so the description must explain results — and it does, covering every headline metric and the health-rating logic. What remains thin is operational context (read-only nature, tenant scoping behavior, aggregation limits beyond what the schema states).

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

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

Schema description coverage is 100%, so both the aggregation window (period 1-90, default 7) and the optional tenant_id scoping are already fully documented in the schema. The description adds no syntax or format detail beyond that, so the baseline of 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 names a specific verb and resource ('Retrieve search analytics summary') and immediately enumerates the returned payload (zero-result rate, latency percentiles, query-type breakdown, top zero-result queries). No sibling in the list overlaps with search analytics, so an agent can identify this tool unambiguously from the name plus description 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?

It states a clear context of use ('for monitoring search quality'), which tells the agent when this tool is appropriate. It does not name any alternative or exclusion, but no sibling tool competes for the same analytics purpose, so the practical guidance gap is small.

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?

No annotations are provided, so the description carries the full burden. It discloses the shape of the response (usage metrics plus over-limit status), which is genuinely useful behavioral context, but says nothing about permissions, whether a missing tenant_id silently defaults to the caller's tenant, or rate/authorization limits.

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

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

Two sentences, zero filler, with the core capability and its monitoring purpose 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?

For a simple single-parameter read tool with no output schema, the description compensates by enumerating the return fields, so an agent knows what it gets back. It stops short of stating the read-only/safety profile, which is the only meaningful gap.

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

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

Schema description coverage is 100% and the single optional tenant_id is fully documented in the schema, including the auth-context fallback. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

The description gives a specific verb (Retrieve) and resource (storage usage details for a tenant) and enumerates the returned fields (bytes used, GB used, storage limit, percentage used, over-limit status). No sibling tool touches storage, so the agent can immediately distinguish it from the Get*/List* asset and prompt 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 ('Helps monitor storage consumption and enforce storage quotas') implies the usage context but never states when to prefer this tool, what prerequisites exist, or any alternative. Usage is inferable rather than explicit.

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

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

With no annotations, the description carries the burden and does well: it discloses that status can be open, closed or expired, that asset_h values are returned per file, and that polling is required rather than assuming completion. It omits auth/permission notes and whether results are cached or eventually consistent, so it falls short of fully rich behavioral disclosure.

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-loaded with the read-back purpose, then chaining guidance, then the polling warning; every sentence earns its place. The first sentence is dense with an embedded colon-list, which slightly reduces scannability but does not waste 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?

There is no output schema and no annotations, so the description must explain return values and it does: status enumeration, asset_h values per file, and conditional digest results. It also supplies the workflow (poll, then feed asset_h to AddToCollection/UpdateAsset/GetAssetDetails), leaving nothing essential missing 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 coverage is 100%, so both tenant_id and upload_link_id are already fully documented and the baseline is 3. The description restates upload_link_id's origin (already in the schema) and mentions expected_sha1, which is not a parameter of this tool, so it adds output-variability context rather than new input-parameter meaning.

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

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

States a specific verb and resource ('Read back an upload link created by CreateUploadLink') and enumerates exactly what is read: open/closed/expired status, asset_h per uploaded file, and digest comparison results. No sibling tool in the list covers upload links, so it is trivially distinguishable and self-contained.

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 trigger ('Poll after asking the user to upload; do not assume the files arrived') and downstream routing ('Use the returned asset_h values with AddToCollection, UpdateAsset and GetAssetDetails'). It does not name an alternative tool for the same job or state when not to call it, but the workflow context is 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that the output is a hierarchical tree, but says nothing about read-only status, auth requirements (tenant_id auto-injection is only in the schema), pagination, or truncation behavior at max_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?

Two tightly packed sentences with zero filler; the core purpose is front-loaded before the filtering note. Nothing could be cut without losing 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 4-parameter list tool with full schema coverage but no output schema and no annotations, the description is minimally adequate. It conveys the tree return shape but does not describe response structure or how counts are returned, which the missing output schema leaves unexplained.

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

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

Schema description coverage is 100%, so all four parameters (max_depth, tenant_id, parent_path, include_asset_counts) are already documented in the schema. The description names the path and depth filters but adds no syntax or format detail beyond what the schema provides, matching the baseline 3.

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 (List) and resource (collections) plus the return shape (hierarchical tree for organizing assets). It is clear what the tool does, though it offers no differentiation from the surrounding List*/Get* 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?

The only guidance is 'Supports filtering by parent path and depth,' which is really a parameter restatement. There is no when-to-use, no exclusions, and no routing against alternatives such as GetCollectionAssets or GetCollectionPublicUrls.

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?

With no annotations, the description carries the full burden. It implies a non-mutating read and notes the presets feed privacy-aware exports (ADR-057), but never states there are no side effects, whether auth/tenant scoping is required, or how tenant_id omission behaves.

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 front-loaded sentences: purpose first, return context second. Minor filler in the app/REST API and ADR-057 aside, but no redundant restatement of the name.

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

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

For a simple optional-parameter listing tool with no annotations and no output schema, the description covers intent but gives no sense of the return shape (fields of a preset) or pagination, so it is adequate rather than 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 coverage is 100% and the single optional tenant_id is fully documented in the schema; the description adds no parameter-level meaning beyond it. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

Specific verb+resource ("List available export presets") plus what it returns ("default options"). No sibling in the list covers export presets, so it is naturally distinguishable, though it never explicitly contrasts with alternatives like ListPipelineTemplates.

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 what is returned and that presets are used by privacy-aware exports, but gives no when-to-use condition, no prerequisites, and no alternatives. An agent gets only implicit usage 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?

No annotations exist, so the description carries the full behavioral burden. It discloses the shape of the return (name, stage count, tags, default execution settings) and implies a tenant-scoped read, but says nothing about pagination, result limits, ordering, or permissions needed to see another tenant's pipelines.

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 with the identity and scope front-loaded, then return shape, then the chaining instruction. No filler, though the enumeration of return fields could be slightly condensed.

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 no annotations, the description sensibly compensates by naming what is returned and how results feed RunSavedPipeline. For a one-parameter, zero-required list tool this is nearly sufficient; only pagination/limit behavior is 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?

The single tags filter is fully documented in the schema, including an example value, so the baseline of 3 applies. The description uses "tags" only to describe returned metadata, which mildly risks confusing the filter parameter with a return field, adding no real clarity beyond the schema.

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

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

States a specific verb and resource ("List saved pipelines") plus a scope qualifier ("for the current tenant"), which separates it from the similarly named ListPipelineTemplates sibling. It doesn't explicitly name or contrast that sibling, so the differentiation is inferential 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?

Gives concrete workflow context: results supply pipeline_definition_h which is then passed to RunSavedPipeline to execute. That tells the agent when this tool sits in a chain, but it never states when to prefer this over ListPipelineTemplates or what conditions would make listing inappropriate.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses the composition of the return set (system vs tenant-specific) and names a key field, but says nothing about permissions required, whether it is strictly read-only, or pagination/result limits for large template libraries.

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 and scope, then return composition, then the follow-up action. No filler; every sentence adds information an agent can act on.

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

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

With no output schema, the description compensates by explaining what the list contains and identifying the field to reuse downstream. It is slightly thin on result size, ordering, or pagination for a tenant that may have many templates, but is otherwise sufficient for a zero-param 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?

The tool takes zero parameters, so there is nothing for the description to clarify; the baseline for a parameterless tool is 4. No misleading parameter hints are given.

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) plus a precise resource (pipeline templates) scoped to the current tenant, and clarifies what the result set contains: system templates plus tenant-specific ones. An agent can distinguish this from the sibling ListPipelines (saved pipelines, not templates) from the description 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?

Gives clear downstream context — take pipeline_definition_h from the results and POST it to /api/v1/pipelines/templates to clone into a saved pipeline — which tells the agent why and when this tool fits in a workflow. It stops short of explicitly contrasting with ListPipelines or stating exclusions, 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?

With no annotations provided, the description carries the full safety-profile burden. It does add useful context by disclosing the returned metadata (name, trigger type, enabled status, linked pipeline) and the tenant scoping, but says nothing about pagination, result limits, or permission requirements.

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

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

Two tight sentences with no filler: the first gives purpose plus scope, the second enumerates the return shape. The most important information (what it lists and for whom) 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?

Although there is no output schema, the description compensates by naming the returned fields, and all three simple parameters are documented in the schema. For a read-only list tool this is nearly complete; only pagination and permission 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 description coverage is 100%, so all three parameters (enabled, tenant_id, trigger_type) are already documented, including the auto-injection of tenant_id. The description only summarizes them as 'optional filters' and adds no per-parameter syntax or interaction detail, 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?

States a specific verb (List) and resource (automation rules) scoped to 'the current tenant', which is clearly distinct from the pipeline/collection/model resources of its siblings. It does not explicitly reference or differentiate itself from any sibling 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?

The mention of 'optional filters' hints that filters may be applied, but there is no guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites stated. Usage must be inferred 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?

No annotations are provided, so the description carries the full behavioral burden. It explains the substitution operation but does not disclose read-only status, authentication requirements, tenant scoping needs, or whether rendering has 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, front-loaded sentence that states the action and mechanism without any wasted words. Appropriately sized for the tool's purpose.

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 three parameters, a nested object, no output schema, and no annotations, the description is minimally viable. It omits return value details, tenant context, and behavioral traits that an agent would need for confident use.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters in detail. The description references placeholders and provided values but adds no parameter-specific meaning beyond what the schema provides.

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 ('Render') and resource ('prompt template') along with the substitution mechanism. It does not explicitly distinguish itself from sibling retrieval tools like GetPrompt, but the action is 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?

Provides no guidance on when to use this tool versus alternatives such as GetPrompt, nor any prerequisites or exclusions. The agent must infer context entirely from the name and 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?

No annotations are provided, so the description carries the full behavioral burden. It states the tool produces aggregate data, but never says whether the stage persists results or is purely computational, what permissions are required, whether it is idempotent, or what the caller gets back — despite the presence of a dry_run flag implying real 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?

Three short sentences, front-loaded with the action and scope, with no filler. The final sentence restating the stage_type values is mildly redundant with the schema enum but costs little.

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 should clarify the return shape and execution side effects, but only says 'aggregate data and statistics.' It also omits how this stage relates to pipelines/templates, leaving the agent to guess at the execution context.

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 assets, config, dry_run and stage_type. The description repeats the stage_type enum values and says nothing about config shape, adding no meaning beyond what the structured schema provides.

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 (Execute), resource (SUMMARIZE-category pipeline stage) and scope (a set of assets), and states the outcome (aggregate data and statistics). It is clearly distinguishable from read-oriented siblings like GetAssetDetails, though it never explicitly says which sibling to prefer.

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

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

There is no when-to-use or when-not-to-use guidance, no prerequisites, and no mention of alternatives such as ListPipelines or GetExperimentSummary. The agent must infer that this is the tool for computing summaries over asset sets.

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