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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only the useful hint that the result includes matched columns, which is somewhat redundant with the existing output schema; it says nothing about how tag matching is resolved or whether results are cached.

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 core question comes first and the return hint second. It is tight, though arguably too terse for a tool taking a required nested-object expression.

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

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

An output schema exists, so return values need no explanation, and annotations carry the mutation/safety story. However, for a tool with three required parameters including a nested tag-to-values object, the description provides no framing on how expressions are interpreted or what a negative result implies.

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 (domain, table, expression) plus the nested tag-map shape are documented in the schema itself with examples. The description contributes no additional parameter meaning, which is the expected baseline 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?

The description states a specific evaluation action ('would this tag-based grant expression reach this dataset') plus an output dimension ('which columns'), so an agent knows this is a hypothetical grant-resolution check rather than a lookup. It doesn't need to differentiate from siblings like find_datasets or get_dataset, which are unrelated operations, but it also never names 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?

There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as get_dataset for actually fetching an existing dataset. The question phrasing weakly implies a policy-authoring/verification context, but the agent must infer that entirely.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower. The description still adds real behavioral context beyond them: the server never reads data, and results are scoped to 'only domains this caller may read' – a permission constraint not visible in 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?

Front-loaded with the core question, and each sentence adds scope or a boundary. The fragmentary 'Answers which datasets hold a kind of data...' slightly restates the opening line, costing 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?

An output schema exists, so return values need no prose. Between the purpose, the negative scope (no row-level data), and the permission scoping, an agent has everything needed to decide and call 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 0% and the single parameter is a nested string map, so the description must carry the load. The example 'subject_type=customer' usefully illustrates the key=value shape, but it does not explain multi-tag semantics (AND vs OR, whether all tags must match).

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 ('which datasets carry these tag values') and clarifies the answer shape ('which datasets hold a kind of data, and in which columns'). It does not name any sibling (list_domains, get_dataset, resolve_lf_tag) to differentiate, so it falls short of a 5.

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

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

Clear usage context is given: use it to map tag values to datasets/columns, and it explicitly excludes row-level queries ('it cannot say where one person's rows are'). However, no alternative tool is named for cases the agent might actually want, leaving routing 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 the safety profile is covered. The description adds the meaningful constraint that only 'published' datasets are returned, but it says nothing about authorization scope or behavior for unpublished/nonexistent datasets. A 3 reflects modest added value over the annotations.

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

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

One compact sentence, front-loaded with the returned attributes, with no redundant or filler text. Every word carries information.

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

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

With an output schema present, the description need not explain return values, and annotations cover safety semantics, so a short scope statement is nearly sufficient. It could still note lookup-by-domain+table behavior or failure behavior, which is the only 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% – both domain and table are documented with examples in the schema. The description adds no additional parameter meaning (e.g., format constraints or domain scoping rules), so the schema does the heavy lifting and 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 names the concrete return payload (schema, ownership, policy tags) and scopes it to 'one published dataset', so the agent knows exactly what it retrieves. It does not, however, distinguish itself from siblings such as find_datasets or resolve_lf_tag, which a reader must infer.

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

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

There is no statement of when to use this tool versus alternatives like find_datasets (search) or list_domains. The phrase 'one published dataset' hints at a targeted lookup, but no exclusions or prerequisites are given.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds a genuine behavioral trait beyond that: results are filtered to "only the domains this caller may read", which tells the agent the output is authorization-scoped and may be incomplete relative to a full domain list.

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

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

Two short sentences, no filler, with the primary purpose front-loaded and the access-scoping caveat immediately after. 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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile; the description therefore only needs purpose plus access scoping, which it provides. It stops short of noting any cap, pagination or ordering behavior, which is a minor residual gap.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. The schema's empty properties object is consistent with the description's implied take-everything-visible semantics.

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

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

States the resource (domains) and the returned attribute (owners) explicitly, so the agent knows it enumerates domains. The verb is implicit ("What domains exist") rather than a direct "List domains", and it does not differentiate itself from siblings like find_datasets or get_dataset, though those operate on a different resource so there is little real confusion.

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

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

Usage is implied rather than stated: an agent can infer this is the enumeration tool for domains and that the caller's read permissions cap the result set. There is no explicit when-to-use/when-not guidance and no pointer to an alternative tool for a narrower lookup.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description goes beyond them by disclosing behavioral fidelity: it replicates the executor's resolution path and failure mode, which is meaningful context for a validation tool. It does not, however, mention anything about ordering, partial validity, or the error shape beyond 'fails the same way.'

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 question front-loaded, and the executor-parity note immediately after. The line break between them is slightly awkward but no sentence 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?

An output schema exists, so return values need not be described, and annotations carry the safety profile. Combined with the executor-parity note, an agent has enough to call this correctly; only the tag-format detail for the lone parameter 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 0% for the single `tags` parameter, and the description adds only the phrase 'tag set' plus the ontology framing — it does not explain the map's key/value shape, tag syntax, or which namespace the keys represent. It compensates partially by grounding validation in a 'governance-owned ontology,' but the parameter remains underspecified.

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 poses a precise question — is this tag set valid against the governance-owned ontology — which names a specific resource (tag set) and operation (validate/resolve). It is clearly distinct from the dataset/domain/grant siblings, though it never names them. Slightly indirect for stating purpose in question form rather than declaratively.

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 implies usage by saying it 'runs the same policy.resolve() the executor runs, and fails the same way,' which tells an agent this is a pre-flight check for executor-time behavior. However, there is no explicit when-to-use/when-not guidance and no alternative sibling is named for comparison.

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