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

With no annotations provided, the description carries the full behavioral burden and fails. It says nothing about required capabilities, what happens on key collision or duplicate titles, whether the group becomes active immediately, or what the call returns (no output schema exists to compensate).

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

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

It is a single front-loaded clause with zero filler, which is structurally sound, but for an 8-parameter mutation tool the brevity reads as under-specification rather than disciplined conciseness.

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

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

A creation tool with no annotations, no output schema, and a nested array payload deserves far more: guidance on the site parameter, the location-rule default (post_type == post), and the auto-generated key behavior. None of that is surfaced in the description.

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 63%, close to the moderate baseline, and the schema itself documents key/site/title/fields/location defaults. The description adds only the word 'fields', which signals that field definitions are supplied inline but adds no syntax, nesting, or default behavior beyond what the schema already states.

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

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

Names a specific verb and resource ('Create an ACF field group') and hints at the nested payload ('with fields'). However it does nothing to distinguish this from siblings such as acf_update_field_group, acf_import_field_groups, or acf_list_field_groups, so an agent must already know the ACF vocabulary to route correctly.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives like acf_import_field_groups (which also creates groups) or acf_update_field_group for existing ones. The agent is left to infer usage 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 full burden. For a destructive operation it fails to state that deletion is permanent/irreversible, whether associated field data or post values are also removed, or whether any capability/permission is required. It says nothing beyond the action itself.

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

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

The single phrase is front-loaded and wastes no words, but at four words it is under-specified rather than concise. Length is not the issue; the absence of any operational detail is.

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

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

A destructive tool with no annotations and no output schema should at minimum warn about permanence and side effects. The description omits everything an agent needs to invoke it safely, leaving only the schema to carry the definition.

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 required parameters (key, site) are documented in the schema, including a pointer to list_sites. The description adds nothing beyond this, 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 states a specific verb (delete) and resource (ACF field group), and the verb alone separates it from acf_create_field_group and acf_update_field_group. However, it is a bare restatement of the tool name with no added scope, so it is minimum-viable rather than helpful.

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

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

No guidance on when to use this versus acf_update_field_group, acf_export_field_group, or acf_list_field_groups, and no mention of prerequisites such as first retrieving the key via acf_get_field_group. Usage is only implied by the verb.

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 export payload format (ACF JSON), which is beyond the schema, but it does not state whether the result is a returned JSON blob or a written file, whether the operation is purely read-only, or what permissions are required.

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 format and purpose are packed into one clause. It is efficient, though nearly too terse to be maximally informative.

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 export tool with no annotations and no output schema, the description should clarify the return shape (JSON string vs download file) and any permission requirements. It covers the format but leaves the consumption contract 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?

Schema description coverage is 100%, so both 'key' and 'site' are already documented in the schema; the description adds no meaning about either parameter. 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 (export) and resource (field group) plus the output format (ACF JSON). This clearly separates it from the sibling acf_import_field_groups and acf_get_field_group, though it never names those alternatives explicitly.

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

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

The parenthetical '(for import/backup)' implies the intended use case, but there is no explicit when-to-use guidance, no prerequisites, and no statement of when to prefer acf_get_field_group or acf_import_field_groups 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?

No annotations are provided, so the description carries the full behavioral burden, yet it only implies read-only via the verb 'get'. It says nothing about authentication/site requirements, error behavior for a missing or invalid key, or whether the returned configuration is the raw stored definition versus resolved values.

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

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

A single well-formed sentence with the resource front-loaded. Nothing is wasted, but there is so little content that there is no real structure to evaluate beyond brevity.

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, an agent needs some hint about the return shape, and 'full field configuration' gives a partial one. With zero annotation coverage, more should be said about what the retrieval guarantees and requires.

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% — 'key' includes a format example (group_abc123) and 'site' points to list_sites — so the schema already does the work. The description adds no parameter-level meaning beyond what is structured, which is the baseline 3 case.

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 specific resource 'ACF field group', and 'with full field configuration' signals the payload is the complete group definition rather than a summary. It is distinguishable from acf_list_field_groups and acf_get_post_field by resource name, though it never explicitly contrasts itself 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 alternatives named. An agent must infer that this is the lookup used once a group key is known (e.g., after acf_list_field_groups) purely from the parameter names.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read but says nothing about whether the field must exist, what happens when ACF is inactive or the field is missing, what permissions are required, or what the returned value looks like for formatted vs raw.

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

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

A single front-loaded sentence with no waste. It is arguably under-specified rather than verbose, but structurally it is clean and immediately parseable.

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 annotations and no output schema, the description must carry the behavioral load for a 4-parameter tool, and it does not. It omits return-value shape and the formatted/raw distinction, leaving real gaps for an agent invoking it.

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% and the description adds nothing beyond it. Most notably it never explains the 'format' enum (formatted vs raw), which is the one parameter whose semantics materially change the result.

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: retrieves one ACF field value from a post. The singular 'single ... field value' implicitly distinguishes it from the plural sibling acf_get_post_fields, though it never names 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?

No explicit when-to-use or when-not-to-use guidance. The word 'single' implies the contrast with acf_get_post_fields (bulk retrieval), but the agent must infer this rather than being routed to the alternative.

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, and it discloses nothing: no permission/auth requirements, no rate or size limits, no statement of what the return looks like, and no explanation of the formatted-vs-raw tradeoff. For a read tool with zero annotation coverage this is a substantial gap.

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

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

A single front-loaded sentence with no filler. It is efficient, though its brevity is a symptom of under-specification rather than disciplined conciseness.

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

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

With no annotations and no output schema, the description must explain the return shape and the effect of the format parameter, and it does neither. An agent cannot tell what structure the ACF field values come back in or how raw output differs.

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%, below the level where the schema alone suffices. The 'format' enum (formatted/raw) has no description in either the schema or the tool description, so the agent gets no explanation of how raw vs formatted changes field values, and 'site'/'post_id' semantics come purely from the schema.

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

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

States a specific verb and resource ('Get all ACF field values for a post'), so the operation is unambiguous. However it does not distinguish itself from the sibling acf_get_post_field (singular) or acf_update_post_fields, leaving the plural/singular choice to inference.

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

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

No guidance on when to use this batch read versus acf_get_post_field for a single field, and no prerequisites or context beyond the one-line purpose. The agent must guess from the tool names alone.

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

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

With no annotations, the description carries the entire behavioral burden and fails to. It is silent on whether imported groups overwrite existing groups with matching keys, whether the operation is idempotent, what happens on malformed JSON, and what permissions are required — all critical for a bulk write 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?

A single front-loaded sentence with no filler or redundancy. It is efficient, though the brevity is partly the cause of the missing behavioral detail rather than a virtue of disciplined writing.

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 bulk import mutation with no annotations and no output schema, the description is too thin. It omits conflict/overwrite semantics, error behavior, and what the caller gets back, leaving the agent unable to predict the effect of the call.

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

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

Schema description coverage is 100%, so both 'site' and 'groups' are already documented in the schema, which sets the baseline at 3. The description's phrase 'JSON export format' loosely ties to the 'groups' array but adds no structural detail (e.g., expected top-level keys) 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 (Import) and resource (ACF field groups) plus the accepted input format (JSON export format). It does not explicitly differentiate itself from the closely related acf_create_field_group or acf_update_field_group siblings, so an agent must infer that this is the bulk/JSON route rather than the single-definition route.

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 alternatives. It never says to prefer this over acf_create_field_group when migrating a full export, nor does it state that a site must be selected first (that hint only exists in the schema description).

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. The verb 'List' implies read-only safety and 'with their fields' discloses return composition, but there is no mention of authentication, permissions, pagination, or whether inactive groups are included.

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 waste. It could be slightly richer without sacrificing conciseness, but it is well-structured and appropriately sized.

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

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

For a simple one-parameter, read-only list tool with no output schema, the description tells the agent what is returned and implies safety. However, it omits usage context and any behavioral caveats that would matter without annotations, leaving it adequate but not complete.

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

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

Schema description coverage is 100% for the single 'site' parameter, so the schema already documents the parameter fully. The description adds no parameter meaning beyond what the schema provides, 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: 'List all ACF field groups with their fields.' Clear enough to distinguish from singular getter acf_get_field_group, though it doesn't explicitly name the sibling or scope (active vs all).

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 alternatives, no prerequisites. The plural 'list all' implies a bulk overview use case, but nothing explains when to prefer this over acf_get_field_group or fields_list_definitions.

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, yet it adds nothing beyond restating the name. It does not disclose that updating fields replaces all existing field definitions (that detail lives only in the schema), nor permissions, reversibility, or side effects for a 9-parameter mutation.

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 wasted words, but its brevity reflects under-specification rather than tight editing. Adequate as a label, thin as documentation.

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 mutation tool with 9 parameters, no annotations, no output schema, and only 56% schema coverage, the description is far too sparse. An agent lacks the destructive-replace semantics, prerequisite site/key context, and field-level guidance needed to call 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 coverage is only 56% across 9 parameters, so the description should compensate by clarifying the under-documented ones (style, active, position, hide_on_screen). It adds zero parameter meaning beyond the schema, leaving several fields unexplained.

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

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

The description states a specific verb (update) and resource (ACF field group), which lets an agent distinguish it from acf_create_field_group, acf_delete_field_group, acf_get_field_group, and acf_list_field_groups. It is clear but offers no additional scoping or sibling-specific nuance beyond the verb.

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 acf_create_field_group for new groups or acf_update_post_fields for values. Usage is only implied by the word 'existing'.

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 of behavioral disclosure. It does not state whether the field must already exist, how the value is validated against the ACF field type, whether the change is reversible, or what permissions are required. For a mutation tool this is a significant gap.

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

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

A single front-loaded sentence with no wasted words. It is appropriately sized for a tool whose parameters are fully documented in the 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?

Given a mutation tool with no annotations and no output schema, the description is too thin. It omits prerequisites (e.g., field existence), side effects, and how the update interacts with ACF field definitions or post state.

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%: all four parameters (site, post_id, field, value) are documented in the schema. The description adds no parameter semantics beyond that, 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 (Update) and resource (a single ACF field value for a post). The word 'single' implicitly distinguishes it from the sibling acf_update_post_fields, but no sibling is named, so it stops short of full differentiation.

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

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

No when-to-use guidance, prerequisites, or alternatives are provided. The agent must infer from the name that this is for one field versus the plural sibling acf_update_post_fields.

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 for a mutation tool. It does not say whether unspecified fields are preserved or overwritten, whether it requires auth, whether it fires hooks or creates revisions, or what it returns — all material for a write operation.

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 efficient sentence with the verb and scope front-loaded and no wasted words. It is arguably under-specified rather than over-long.

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 nested-object mutation tool with no annotations and no output schema, the one-line description leaves key behaviors unexplained — merge vs replace semantics, permission needs, and error/return behavior. It should say more.

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

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

Schema description coverage is 100%, with each parameter documented (site, post_id, fields) including a pointer to list_sites. The description adds no syntax or format guidance beyond the schema, so baseline 3 is appropriate.

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

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

States a specific verb (Update) and resource (ACF field values) scoped to a post, and the word 'multiple' distinguishes it from the singular sibling acf_update_post_field. It does not explicitly name that sibling, 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?

The description gives no when-to-use condition, no alternative tools, and no prerequisites. The only implied hint is the plural 'multiple', which suggests bulk updates, but the agent is left to infer when to pick this over acf_update_post_field.

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 does disclose one concrete behavioral trait — a 409 error when the key already exists — which is useful and non-obvious. However, it omits permission/auth requirements, whether creation is reversible, and the side effects of creating a post type or taxonomy (e.g., rewrite rule registration).

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

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

One sentence plus a short failure clause, with the core action front-loaded and zero filler. 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 mutating, nested-object tool with no annotations and no output schema, the description covers what is created and one error mode, but omits prerequisites (site id resolution via list_sites, schema lookup via fields_get_schema), auth requirements, and any return information. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters, including the kind enum and the 'definition' object's shape reference to fields_get_schema. The description adds no syntax, format, or constraint detail beyond restating the kinds, 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 ('Create') and resource ('definition'), and enumerates the four kinds (field group, post type, taxonomy, options page) that map to the 'kind' enum. The verb distinguishes it from siblings like fields_update_definition or fields_delete_definition, though those alternatives are never named 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?

No when-to-use guidance, no prerequisites, and no routing to alternatives. It states a failure condition (409 on existing key) but never tells the agent when to choose create over update/sync, or that fields_get_schema should be consulted first even though the schema references it.

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 does disclose one valuable, non-obvious side effect — stored field values remain in post/term/user meta and options after the definition is deleted — but omits permissions required, reversibility, and what happens to now-orphaned values.

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

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

Two short sentences, the destructive action front-loaded and the persistence caveat immediately after. 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 destructive mutation tool with no annotations and no output schema, the description covers the key data-persistence consequence but leaves auth/permission requirements and reversibility unstated, so it is only partially 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% with clear descriptions for key, kind (with enum), and site, so the schema does the heavy lifting. The description adds only indirect context about where values live, without extra semantics for any parameter.

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

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

States a specific verb+resource ('Delete a database definition'), and the schema's enum clarifies the four kinds of definitions involved. It does not explicitly distinguish itself from siblings like fields_update_definition or fields_sync_definition, but the field-family naming and the 'delete' verb make the intent 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives (e.g., fields_update_definition or fields_sync_definition when you only want to change or refresh a definition rather than remove it). The agent must infer context 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 full disclosure burden. 'Get' implies a read-only operation, but nothing is said about permissions, whether a missing definition errors or returns empty, or how the definition relates to sibling 'definition' resources. This is thin for a tool with zero annotation coverage.

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

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

A single short sentence with the lookup keys front-loaded and no waste. It is efficient, though arguably under-specified rather than genuinely concise.

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

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

For a 3-required-parameter getter with no output schema and no annotations, the description should clarify what a 'definition' is, what the returned object looks like, and how it pairs with fields_list_definitions/fields_update_definition. None of that is present, leaving an incomplete picture 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%: key, kind, and site are each documented in-schema, including the enum for kind and the key pattern. The description only restates 'kind and key' and omits the required 'site' parameter, so it adds no meaning beyond the schema — 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?

States a specific verb+resource ('Get one definition') and constrains it by 'kind and key', which distinguishes it in spirit from siblings like fields_list_definitions and fields_get_schema. However, it never names those siblings, so the differentiation is implicit rather than explicit.

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

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

There is no guidance on when to use this versus fields_list_definitions, fields_get_schema, or fields_get_settings. An agent must infer the selection rule 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 burden. It discloses the categories of values returned, which sets expectations, but it does not explicitly state that the operation is read-only, whether it has side effects, or what the response structure looks like. For a simple retrieval tool this is minimally adequate but incomplete.

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 line that front-loads the value domain and contains no filler. Every word contributes to identifying what values the tool returns. The telegraphic noun-phrase style is appropriate for a simple getter.

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

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

Given a one-parameter read-only tool with a fully described schema and no output schema, the description identifies the value categories but leaves the return shape (e.g., list vs. grouped object) and usage context unspecified. It is borderline adequate but an agent would still need to inspect other resources to use 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 description coverage is 100%: the sole parameter 'site' is fully documented in the schema with a pointer to list_sites. The description adds no additional meaning about the parameter. The baseline is 3 because the schema already does the work of documenting the parameter.

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

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

The description states that this tool retrieves values used in field-group location rules and enumerates the value categories (post types, page templates, taxonomies, options pages, user forms). The name supplies the verb 'get' and the resource is clear. It distinguishes from sibling schema or definition tools, though it does not state a verb or scope in the description itself.

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

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

The description offers no when-to-use guidance, prerequisites, or alternative tools. The phrase 'usable in field-group location rules' implies a context, but it does not tell an agent when to call this versus fields_get_schema, fields_list_definitions, or other field tools.

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

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

With no annotations, the description carries the full burden. It discloses the workflow dependency (call before create/update) and implies a read-only schema fetch, but says nothing about permissions, whether the schema varies per site/kind, or any rate/access constraints.

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 resource stated first and the routing instruction second. 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 two-param, read-only schema getter with no output schema, the description is nearly sufficient: it states the resource and the workflow position. It stops short of hinting at the schema's shape, which would help since no output schema exists.

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 kind enum is fully documented in the schema, so the baseline is 3. The description adds only "fields and their options" about the return, not new meaning for the site or kind 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?

Names a specific verb and resource: retrieve the editor form schema for one definition kind, with a parenthetical clarifying it returns fields and their options. This distinguishes it from sibling readers like fields_get_definition and fields_list_definitions, though it doesn't explicitly contrast 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?

"Read it before fields_create_definition / fields_update_definition" gives explicit ordering guidance that selects this tool over its siblings. No when-not conditions or prerequisites are stated, but the sequencing rule is unambiguous.

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 burden and does so well: it discloses that the GitHub update token is returned only as { set: boolean } and never raw, plus that JSON sync path and writability are included. This is meaningful behavioral/pitfall context beyond the schema. It doesn't spell out permission requirements, which is a minor gap.

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

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

Two tight sentences, front-loaded with the core action, then the key return-value caveat. Every clause earns its place with zero filler.

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

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

With no output schema, the description usefully summarizes the notable return fields (token redaction state, sync path, writability). It doesn't enumerate the full settings payload, but for a simple one-param getter it is nearly complete.

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

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

Schema coverage is 100% and the single 'site' parameter is fully documented in the schema, so baseline is 3. The description adds no syntax or format detail about the site parameter 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+resource ('Get cvrt-fields settings'), clearly distinguishing it from the sibling fields_update_settings. However, it does not explicitly name its siblings or scope against fields_status/fields_get_schema, so it stops short of full differentiation.

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

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

Usage is implied by the read-only getter nature (read settings before changing them), but there is no explicit when-to-use, when-not, or routing to alternatives like fields_update_settings. Adequate but leaves the agent to infer context.

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

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

No annotations, so the description carries the burden; 'List' implies a read, and it usefully discloses that results aggregate across database, JSON, and PHP sources with a _source field on each item. It does not state permissions, result size, or pagination, which matters since there is no output schema.

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

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

A single tightly front-loaded sentence with no filler; the source scope is stated before the modifier. The trailing 'with their _source' is slightly cryptic but still earns its place by hinting at return content.

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?

Two required parameters are fully schema-documented, so the callable surface is complete. With no output schema and no annotation coverage, the description stops short of explaining what a 'definition' contains or how many come back, leaving a modest 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%, with the 'kind' enum fully enumerated and 'site' pointing to list_sites, so the schema does the heavy lifting. The description only reinforces the 'one kind' and 'every source' framing, adding little 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 (list) and resource (definitions) with a distinguishing scope clause: 'of one kind from every source (database, JSON, PHP)'. However it never disambiguates 'definitions' from neighbors like fields_get_definition or acf_list_field_groups, so an agent must infer the relationship.

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

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

No when-to-use guidance at all. With siblings such as fields_get_definition, fields_list_types, and acf_list_field_groups, the description gives no condition for choosing this tool or any exclusion, leaving the agent to guess.

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 not explicitly state that this is a read-only operation, whether it requires elevated permissions, or what the response format looks like beyond 'with their settings'.

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

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

The description is a single, front-loaded sentence that states the action and the return content, with helpful examples. There is no redundant or wasted text.

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

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

For a simple list tool with no output schema, the description adequately explains what is returned (field types with settings). It could be slightly more complete by mentioning the site scope or read-only nature, but the essential context is present.

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 schema already documents the single 'site' parameter with a pointer to list_sites. The description adds no additional parameter syntax or meaning beyond what the schema provides, so the baseline score 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 and resource: 'List the available field types ... with their settings', and gives concrete examples of field types. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools such as fields_list_definitions or fields_get_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 description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It only states what the tool returns, leaving the agent to infer appropriate usage.

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 does disclose useful behavioral details: what data appears in the response (version, counts, plugin states, sync state, error condition). However, it doesn't state whether this is a read-only operation (implied but not explicit), whether it requires authentication, or whether it's safe to call frequently. For a status tool with no annotation coverage, the description provides moderate but incomplete behavioral context.

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

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

A single compact sentence that enumerates the returned fields in a terse, comma-separated list. It is efficiently front-loaded with the tool's subject ('cvrt-fields status') and wastes no words. The telegraphic style trades some readability for brevity, but stays clear.

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 diagnostic tool with one schema-documented parameter, the description covers what an agent needs to know about the output at a high level. No output schema exists, so the field enumeration is helpful, but it doesn't explain return format, pagination, or failure modes beyond mentioning a 'JSON read error' item. Adequate but with room for more detail on what each reported field means.

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 there is only one parameter ('site'), fully documented in the schema with a pointer to list_sites. The description adds no additional parameter information (no format hints, no edge cases). Baseline 3 is appropriate when the schema does all 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?

States a specific resource (cvrt-fields status) and enumerates exactly what the status report contains: plugin version, definition counts per kind, plugin active states, JSON sync state, and JSON read error. This gives an agent a clear picture of the tool's diagnostic purpose. Loses a point because it doesn't differentiate from siblings like seo_status, legal_status, or fulfillment_status, though the domain prefix 'cvrt-fields' provides implicit scoping.

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 usage for diagnostics (checking plugin version, active plugins, sync state) but gives no explicit when-to-use guidance, no statement about when not to use it, and no alternatives. An agent can infer this is a status-check tool, but is left to decide independently when it's warranted over generic health checks like mcp_get_health or mcp_get_plugins_health.

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 supplied, so the description carries the full behavioral burden. It implies a database write ('Copy ... into the database') but does not say whether an existing definition is overwritten, whether prior DB state is lost, what auth is required, or how conflicts between JSON and DB versions are resolved — significant gaps for a mutation 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?

Two short sentences, zero filler, with the core action front-loaded and the precondition immediately after it. Nothing could be removed without losing meaning.

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 write tool with no annotations and no output schema, the description covers the core action and one precondition, and the schema fully documents the parameters. However, the consequences of syncing (overwrite semantics, return value, error cases) are absent, leaving the agent under-informed about the operation's effect.

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

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

Schema description coverage is 100%, with site, kind (enum of four definition types) and key all documented in the schema itself, so the baseline is 3. The description adds 'JSON-sourced' framing but no syntax, format, or default info beyond what the schema already states.

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

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

States a specific verb ('Copy ... into the database') and resource ('JSON-sourced definition'), and the qualifier 'JSON-sourced' distinguishes it from the sibling fields_create_definition/fields_update_definition. It doesn't explicitly name those siblings, so an agent must infer the boundary, keeping it at a 4 rather than 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?

'Only JSON definitions can be synced' gives one exclusion condition, which is real guidance, but it never says when to prefer this over fields_create_definition or fields_update_definition, nor what to do if the definition is not JSON-sourced. Usage is implied rather than routed.

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 adds real value by disclosing a specific failure mode (409 cvrt_fields_json_shadowed: a read-only JSON file still overrides the DB copy), but it omits whether the operation overwrites irreversibly, what permissions are required, or what happens to unspecified fields.

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

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

Two short, front-loaded sentences with no filler; the primary action leads and the error hint follows. The terseness borders on under-specification, but nothing 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?

The schema fully documents the four required parameters and the definition object shape, so the inputs are covered. But for a destructive replacement tool with no annotations and no output schema, the description leaves mutation semantics and prerequisites 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%, with all four parameters documented in the schema itself, including the 'definition' object's reference to fields_get_schema. The description adds nothing about parameter format or constraints, 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 ('Replace a definition'), which is clear enough to distinguish from fields_create_definition and fields_delete_definition. However, it never names those siblings or clarifies that this is a full overwrite of an existing definition, so routing still requires 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?

Provides no when-to-use guidance and never references alternatives like fields_create_definition or fields_sync_definition. The 409 note is diagnostic context, not a usage condition, so the agent must infer all invocation criteria.

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

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

With no annotations, the description carries the full burden and does real work: it discloses that github_token is write-only and stored encrypted, that a blank/omitted token preserves the existing value, and that clear_github_token:true deletes it. It still omits permission/authentication requirements and whether the update is reversible, so it falls short of a 5 for an unannotated mutation 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?

Two compact sentences, front-loaded with the core action and followed by the non-obvious token handling rules. No filler and 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 3-parameter settings mutation with no annotations and no output schema, the description covers the two non-obvious params thoroughly and the third via the schema reference. It stops short of stating permissions or the response, but nothing critical to invoking it correctly is missing.

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

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

Schema description coverage is only 33% (only `site` is documented), but the description compensates by explaining the semantics of the two undocumented params: write-only/encrypted storage, blank-keeps semantics for github_token, and the delete behavior of clear_github_token. The `site` param is left to the schema.

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

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

States a specific verb+resource ("Update cvrt-fields settings") that an agent can pair with the read-side siblings fields_get_settings / fields_status. It is clear, but it does not explain what "cvrt-fields" is or differentiate itself from the other fields_* tools beyond the update verb.

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 or when-not-to-use guidance and no mention of the read counterpart. The mutation semantics are implied by the verb and by the surrounding fields_get_settings/fields_status siblings, which is the minimum viable level.

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 the idempotency guard bypass, the concrete risk (duplicate ClickUp task), the side effects (packing slip, task, Slack notification), and that actions are audit-logged. This is exactly the kind of consequence information an agent needs before a destructive re-run.

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 the action and its consequences front-loaded; no filler, 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 mutation tool with no annotations and no output schema, the description covers behavior and risk thoroughly. It stops short of describing the return value or any permission prerequisite, which would fully close the 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 'site' and 'order_id' are documented in the schema, including a pointer to list_sites. The description adds no parameter-level detail, so the baseline 3 applies.

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

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

States a specific verb (run fulfillment), the resource (an order), and enumerates the concrete effects (packing slip, ClickUp task, Slack). It is clearly differentiated from siblings like fulfillment_queue and fulfillment_reprint_job, which do not force a full re-run.

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?

'Manually (force)' implies the tool is for deliberate manual invocation rather than the normal automated path, but it never names an alternative (e.g. fulfillment_queue) or states when NOT to use it. Usage context is implied, not spelled out.

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, and it delivers a genuinely non-obvious behavioral trait: secret values are masked as { set: boolean } and never returned raw. That is exactly the kind of context an agent needs before reading settings. It stops short of stating auth requirements or read-only confirmation, but the masking disclosure is substantive.

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

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

Two tight sentences with no filler; the resource scope is front-loaded and the return-shape caveat follows immediately. 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?

With no output schema and no annotations, the description correctly compensates by explaining the shape of sensitive return values. What an agent needs to call this safely and interpret secrets is largely present, though the full non-secret return shape 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?

Schema description coverage is 100% and the single 'site' param is already documented as 'Site id (see list_sites)'. The description adds no syntax, default, or format detail 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 ('Get') and a precisely scoped resource ('cvrt-order-fulfillment plugin settings'), which separates it from siblings like fulfillment_status or fulfillment_queue. It does not explicitly name the contrasting sibling (fulfillment_update_settings), but the resource is unambiguous.

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

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

There is no when-to-use guidance: nothing says to call this to inspect configuration before fulfillment_update_settings, nor any prerequisite or exclusion. Usage is only implied by the getter/updater naming convention among siblings.

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

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

With no annotations, the description carries the full burden. It usefully discloses return content (counted states and job error details), which is real behavioral value, but it never confirms this is a read-only operation, nor whether results are paginated or scoped by time, so a caller cannot fully predict behavior.

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

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

A single front-loaded sentence fragment with no padding; the resource comes first and the payload follows. It loses a point only for being a noun phrase rather than a statement of what the tool does.

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 tool with no output schema, describing the returned counts and job errors partly compensates, but the absence of annotations, output schema, and any usage context leaves gaps about safety and when this tool should be preferred over the related fulfillment_status 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?

Only one parameter exists and the schema documents it fully ('Site id (see list_sites)') at 100% coverage, so the baseline is 3. The description adds nothing about the site parameter or its implications for the queue returned.

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 resource (the print/fulfillment queue) and enumerates what it exposes: status counts across four states and recent jobs with errors. That is well beyond a tautology. It does not, however, differentiate itself from the sibling fulfillment_status, which an agent could easily confuse with it.

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

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

There is no explicit guidance on when to call this versus fulfillment_status, fulfillment_get_settings, or fulfillment_update_check. The nearest-sounding sibling (fulfillment_status) is not mentioned, leaving the agent to infer the distinction from the names alone.

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

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

With no annotations, the description carries the full behavioral burden; it does disclose the core state transition (job goes back to pending and is re-printed), which is genuinely useful. It omits side effects an agent should know: whether this creates a duplicate print, what happens if the job is already pending or already completed, and any 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?

One sentence, front-loaded with the action and the state change, with no filler. Every word contributes to understanding the operation.

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 mutation tool with full schema coverage and no output schema, the description covers the essential action but leaves out error/edge-case behavior and the conditions under which reprinting is appropriate. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, so 'site' and 'job_id' are already documented in the schema, including where job_id comes from (fulfillment_queue). The description adds no parameter-level 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 and resource ('Reset a print job to pending') and adds the intended effect ('so the agent prints it again'), so an agent knows exactly what operation this is. It does not explicitly differentiate itself from the nearby fulfillment_* siblings such as fulfillment_queue or fulfillment_fulfill_order, which keeps it from 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 phrase 'so the agent prints it again' implies the use case (recovering a job that needs reprinting) but gives no explicit when-to-use condition, prerequisites, or named alternative such as fulfillment_queue. Usage is inferable 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?

No annotations are provided, so the description carries the full behavioral burden. It lists the returned fields but never states that this is a safe read with no side effects, nor does it mention permissions or rate limits. For a status endpoint, the omission is notable though partially implied by 'pipeline health.'

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 opens with the category ('Pipeline health') and then enumerates the components. It is efficient with no filler, though the colon-list format is terse rather than maximally informative.

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, no-annotation, no-output-schema tool, the description usefully compensates for the missing output schema by enumerating what is returned. However, it leaves gaps around when to use it versus sibling fulfillment diagnostics and does not state that it is read-only.

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 with 100% schema description coverage, so the schema already defines 'site' as a site id referencing list_sites. The description adds no parameter information, which meets the expected baseline when schema coverage is high.

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 this is a pipeline-health status report and enumerates its contents (credentials, ClickUp list/assignee, last poll, queue counts). It is a clear read-only diagnostic rather than an action, but it does not explicitly differentiate itself from siblings like fulfillment_queue or fulfillment_get_settings.

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

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

No guidance is given on when to call this versus the many fulfillment siblings. There is no mention of prerequisites, intended audience, or conditions that select this diagnostic over fulfillment_get_settings or fulfillment_queue.

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 meaningful work: it discloses the exact mechanism (WordPress's own upgrader, same code path as one-click wp-admin update), the mutation being applied, the returned fields { applied, from, to }, and that the action is audit-logged. It does not address reversibility/rollback, permissions, or whether the site is briefly unavailable during install.

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, then the mechanism, then the result contract. No filler and nothing an agent must dig for.

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 mutation tool with no annotations and no output schema, the description supplies the missing return-shape information ({ applied, from, to }) and confirms audit logging. The notable gap is safety context: no statement about failure handling, rollback, or interruption during install.

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 ('site') and the schema documents it at 100% coverage ('Site id (see list_sites)'), so the schema already does the work. The description adds no further syntax or sourcing guidance beyond what the schema provides, matching the baseline for high-coverage 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?

The description gives a specific verb and resource ('Install a pending cvrt-order-fulfillment update') and scopes it to pending updates, making it distinguishable from the read-only sibling fulfillment_update_check. It stops short of naming that sibling, so the differentiation is implied rather than explicit.

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

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

The word 'pending' implies a precondition (something must first report an available update, i.e. fulfillment_update_check), but the description never states when to call this versus checking, nor any exclusions. Usage is inferable but not spelled out.

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 must carry the behavioral burden. It usefully discloses that it bypasses PUC's throttle and is rate-limited to about once per 30 seconds, but it does not address permissions, whether any state is modified, or what a response contains.

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

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

Two sentences are front-loaded with the action and outcome, followed by the critical rate-limit constraint. Every sentence earns its place with 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 single-parameter check tool with no output schema and no annotations, the description covers the core behavior, outcome, and rate limit. It could be slightly more complete by clarifying whether the check is read-only or by naming related alternatives.

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 single site parameter is already documented in the schema as a site id referencing list_sites. The description adds no additional parameter meaning beyond the schema baseline.

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

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

The description states a specific verb and resource: force an immediate plugin-update check and report whether a newer version is available. It is clearer than a tautology and mentions the PUC throttle, but it does not explicitly distinguish itself from sibling update-check tools such as mcp_check_updates.

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: use it when an immediate, throttled update check is needed. It does not name alternatives or say when not to use it versus mcp_check_updates or update-related siblings.

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

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

With no annotations, the description must carry full behavioral disclosure. It does reveal a key safety trait—omitted secrets are never wiped—and implies partial update semantics. However, it omits other relevant behavior such as authentication requirements, whether the update is reversible, and what happens to non-secret fields when omitted.

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-loaded with purpose, then the partial update rule, then the key list. The key list is somewhat redundant with the schema properties, but it aids quick reference. No wasted sentences overall.

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

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

Given 8 parameters, no annotations, no output schema, and very low schema description coverage, the description is incomplete. It lacks any explanation of what the secret tokens and IDs are for, does not mention authentication or site selection, and does not describe the return value (e.g., updated settings).

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 13% (only 'site' has a description). The description lists the key names but adds no per-parameter meaning beyond what the schema property names already convey, and it does not explain expected formats or purposes (e.g., what each token is for). It does mention partial updates, but that is a usage rule, not parameter 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?

The description states a specific verb ('Update') and resource ('cvrt-order-fulfillment settings'), making it immediately clear what the tool does. It implicitly distinguishes itself from the sibling fulfillment_get_settings (which reads) without needing to name it.

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

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

It gives clear usage context: 'Only provide the keys you want to change' and explains that blank/omitted secrets keep the stored value. This is explicit guidance on how to invoke it for partial updates, though it does not name alternative tools or when-not-to-use conditions.

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 that the call returns a resolved slug for shortcode addressing, but says nothing about permissions, whether changes are reversible, whether 'body' is sanitized, or what happens if the section already 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?

Two short sentences with the action front-loaded and the return-contract second; nothing is wasted. It is efficient, though very brief for a 6-parameter mutation 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?

For a 6-parameter mutation tool with no annotations, no output schema, and only partial schema coverage, this description is too thin. It omits the invocation context an agent needs (document must exist, HTML body format, slug behavior) and relies on the name alone.

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 67% (slug and heading lack descriptions) and the description adds no parameter meaning at all - it never mentions site, doc, heading, body, slug, or level. With moderate coverage and zero compensating detail, this is weak.

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 ('Append a section to a legal document'), which clearly separates it from the update/delete section siblings. It does not explicitly name those siblings, 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?

There is no guidance on when to use this versus legal_update_section or legal_delete_section, nor any prerequisites (e.g. does the document need to exist first). Usage must be inferred entirely from the name.

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

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

With no annotations, the description carries the burden and does well: it discloses the manage_options auth requirement, the return shape { filename, csv }, that the csv is writable as-is, the logging prerequisite tied to legal_put_consent's log_enabled, and a cvrt-legal 0.5.0+ version gate. It stops short of explicitly labeling the operation read-only/side-effect-free, which would complete the behavioral picture.

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

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

Front-loads the core action and packs prerequisite, return shape, and version into compact sentences, each carrying distinct information. Slightly dense but nothing is redundant.

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

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

Despite no output schema, the description explains the return value, and it covers auth, prerequisites, version requirements, and parameter semantics. An agent has everything needed 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 100%, so the from/to/site parameters are already documented in the schema; baseline is 3. The description's cross-reference to legal_consent_log_stats for from/to rules adds minor value but no new syntax or format detail beyond the schema.

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

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

States a specific verb and resource ('Export the raw consent decision log as CSV') and notes it uses the same from/to rules as legal_consent_log_stats, which implicitly distinguishes it from that stats sibling and from legal_consent_log_get. An agent can tell what it produces (a CSV file) 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?

Frames usage by referencing legal_consent_log_stats for the day-range semantics, giving clear context on the family. It does not spell out explicitly when to prefer this over legal_consent_log_get or when-not to use it, but the 'raw log' vs statistics distinction is inferable.

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 burden, and it does disclose meaningful behavior: the required capability (manage_options), the default-off logging state that gates whether any data exists, the dependency on legal_put_consent's log_enabled flag, and a version requirement (cvrt-legal 0.5.0+). It does not describe return shape or pagination, but the behavioral gating context is unusually 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?

Three sentences, front-loaded with the core action and resource before the prerequisites. Dense but every sentence earns its place; the version note at the end is a minor trailing detail rather than 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 annotations and no output schema, the description adequately covers what the tool does, who can call it, and the configuration state that must precede it. It stops short of describing the returned record's fields or pagination behavior, which an agent might want for a log-listing tool, but nothing critical for correct invocation is missing.

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

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

Schema description coverage is 100%, so both parameters are already documented, giving a baseline of 3. The description reinforces that consent_id is a per-visitor banner identifier, but adds little beyond the schema's own 'The consent_id the banner generated for one visitor' and does not explain 'site' or format expectations.

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 ('every logged consent decision') scoped to a single consent_id, and the parenthetical clarifies exactly what the data represents ('the banner's own record of what it asked and what the visitor chose'). An agent can distinguish this per-visitor lookup from siblings like legal_consent_log_export (bulk) and legal_consent_log_stats (aggregate) without opening a 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?

Provides clear preconditions: requires manage_options, logging must be enabled via legal_put_consent's log_enabled, and the Datenschutz document should carry an 'einwilligungsnachweis' section first. This implicitly warns that the tool returns nothing until logging is on, which is valuable routing context, though it never names an alternative tool explicitly.

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 the auth requirement (manage_options), the dependency on legal_put_consent's log_enabled flag, the Datenschutz 'einwilligungsnachweis' prerequisite, and a minimum plugin version. It stops short of describing behavior when logging is off (empty result vs error) or result shape detail.

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 aggregation purpose is front-loaded in the first clause, followed by range/limit rules and prerequisites. It is somewhat dense with prerequisite prose (Datenschutz section name, version pin) but each sentence conveys operative constraints.

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 no-annotation, no-output-schema tool, the description covers purpose, required permission, dependency/enablement conditions, and range limits, and it is self-sufficient for correct invocation. Return-value formatting is not spelled out, but the grouping dimensions are stated.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds the 366-day cap on from/to (absent from the schema) and clarifies the optionality/defaults. This is meaningful additive context beyond the schema's per-parameter descriptions.

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 (aggregate) and resource (consent decision counts) with dimensions (by action and banner_version) and scope (day range). It is clearly distinguishable from siblings like legal_consent_log_get/export by being a stats aggregation, though it does not name those alternatives directly.

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 operating context: requires manage_options, defaults to last 30 days, cannot exceed 366 days, and logging must be enabled via legal_put_consent's log_enabled. It does not explicitly say when to prefer this over legal_consent_log_get/export, so it falls short of full when-not/alternative 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?

No annotations are provided, so the description carries the full burden. It states the mutation but discloses nothing about reversibility, permissions required, whether child content or references are cascaded/removed, or the effect on the rendered document.

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 or redundancy. It is efficient, though the extreme brevity reflects under-specification rather than tight editing.

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

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

For a destructive mutation tool with no annotations and no output schema, the description should explain the consequence of deletion and any safeguards. It provides none of that, leaving the agent to guess about destructive behavior.

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

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

Schema description coverage is 100%, with all three params (site, doc, slug) documented and an enum on doc, so the baseline of 3 applies. The description adds no extra meaning such as slug format or where slugs originate.

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 (delete) and resource (section of a legal document), which is unambiguous. It does not differentiate itself from close siblings such as legal_add_section or legal_update_section, 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?

No guidance on when to use this versus legal_update_section or legal_add_section, and no prerequisites or preconditions stated. The agent must infer usage entirely from the name.

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

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

No annotations are provided, so the description carries the full burden. 'Get' correctly signals a read, and the enumerated settings reveal what the call surfaces, but there is no statement about permissions, whether missing settings are returned as defaults, or how the tool list relates to the settings payload.

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 the verb and resource front-loaded; the parenthetical field list earns its place by previewing the payload. No filler or redundancy.

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

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

For a single-parameter read tool with no output schema, the description covers what is returned and states the plugin version prerequisite. Only return-value formatting is left unspecified, which is not required since no output schema exists.

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?

One parameter with 100% schema description coverage ('Site id (see list_sites)'), so the schema already fully documents the input. The description adds nothing about the site parameter, which is acceptable at baseline 3 given the complete 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?

The description gives a specific verb ('Get') and resource ('the self-hosted accessibility tool's settings') and even enumerates the returned fields (enabled, position, colour, tools, statement link) plus the tool list. It is unambiguous, though it never names its write sibling legal_put_accessibility or distinguishes itself from legal_get_accessibility_report.

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

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

'Requires cvrt-legal 0.8.0+' is a genuine prerequisite an agent needs before calling. However, there is no explicit when-to-use guidance and no routing to the sibling legal_put_accessibility or legal_get_accessibility_report, so usage is only implied by the read-only verb.

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 disclose real behavioral traits: a per-page recording cap of once a day, a bounded window of the newest 100 pages, and a minimum plugin version. It still omits permissions/auth requirements and whether the read is non-mutating, which keeps 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?

Two dense sentences with the resource and its payload front-loaded, followed by the retention window and version requirement. Nothing is redundant and every clause adds 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 single-parameter read tool with no output schema and no annotations, the description adequately covers what the report contains and its data window. It lacks permission/error context, but the return-value semantics — the main risk here — are well covered.

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

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

Schema description coverage is 100% and the single 'site' parameter is already documented as 'Site id (see list_sites)' in the schema. The description adds no format, id-source, or constraint detail beyond that, 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 ('Get') and a specific resource ('the markup repair report') and then enumerates its contents (totals per rule, per-page fixed/open items). This is far more precise than a tautology, though it never names the adjacent siblings (legal_get_accessibility, legal_reset_accessibility_report) to draw an explicit boundary.

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

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

Usage is only implied by the content description — an agent can infer this is the diagnostic report reader, but there is no when-to-use/when-not statement and no pointer to legal_get_accessibility for settings. The 'Requires cvrt-legal 0.9.0+' line is a useful prerequisite but is not usage 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?

There are no annotations, so the description must carry the full behavioral burden. It does not disclose whether the operation is read-only, what authentication or capability is required, whether the configuration may be missing, or what the response contains beyond the generic term 'configuration'.

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

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

The description is a single front-loaded sentence with no filler or repetition. It is succinct, though the extreme brevity leaves important usage and behavioral details unaddressed elsewhere.

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

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

For a simple one-parameter getter with no output schema, the description identifies the returned subject but not the return shape, error behavior, or relationship to sibling legal tools. With no annotations and no output schema, more context would help an agent avoid 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?

The single parameter has 100% schema coverage, with the schema itself describing site as 'Site id (see list_sites)'. The description adds no additional meaning, format, or constraints beyond the schema, so the baseline score 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 names a specific verb-object pair: retrieving the cookie consent banner configuration. That is clear enough to distinguish it from generic getters like wp_get_settings, but it does not explicitly contrast with sibling legal_get_settings or legal_put_consent.

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

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

No guidance is given about when to call this tool, required permissions, or alternatives. The description simply states the outcome and leaves the agent to infer that a site id must be passed and that legal_get_settings or legal_put_consent are related.

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 usefully states that the result includes ordered sections and implies a read-only operation via 'Get', but it does not disclose authentication needs, error behavior, or broader return structure.

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

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

The description is a single front-loaded sentence with no wasted words. It immediately states the action, scope, and notable output characteristic.

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 getter with no annotations and no output schema, the description is minimally adequate. It says what is retrieved and that sections are ordered, but it does not fully compensate for the lack of output schema or usage guidance.

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 both parameters, including the 'doc' enum and the 'site' reference to list_sites. The description adds no additional parameter meaning beyond the schema, making the baseline of 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 states a specific verb (Get) and resource (legal document), and scopes it to exactly one document with its ordered sections. This clearly distinguishes it from the plural sibling legal_list_documents without requiring the schema to be opened.

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

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

The description gives no explicit when-to-use conditions, prerequisites, or alternatives. It does not mention siblings like legal_list_documents or legal_get_page, so the agent has to infer that this is the right tool for retrieving a single legal document.

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 must carry the behavioral load, and it does disclose a concrete prerequisite ('Requires cvrt-legal 0.7.0+') plus a non-obvious behavior: it also reports which required fields are missing. It does not mention auth/permission needs, but the version gate and missing-field reporting are real added context.

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

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

Two sentences, no filler, with the core action and returned content front-loaded and the version prerequisite placed at the end. 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?

There is no output schema, so the description usefully describes what comes back (Impressum field values plus missing-required indicators). Combined with the version prerequisite and 100% param coverage, an agent has enough to call this tool correctly, though permissions/error behavior remain 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 (site) with 100% schema description coverage, so the schema already explains it ('Site id (see list_sites)'). The description adds nothing about parameter semantics, 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?

States a specific verb (Get) and resource (Impressum fields: company, address, register, VAT id) and clarifies downstream use (generator fills both Impressum and Datenschutz). That distinguishes it cleanly from the sibling writers legal_put_facts and legal_update_settings.

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

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

Usage is only implied by the name and the fact that it returns field values; there is no explicit when-to-use statement or pointer to alternatives such as legal_put_facts for writing or legal_get_generator for generator config. Adequate but with a clear gap.

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 behavioral burden, and it does disclose the shape of the returned state (active flag, library loaded, ticked modules/options/kept custom sections, sections written) plus a runtime prerequisite (cvrt-legal 0.7.0+). It omits any auth/permission or read-only assurance, but the return-structure disclosure is genuinely useful given there is no output schema.

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

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

One dense, front-loaded sentence that puts the operation and its return contents first and the version prerequisite last. The parenthetical enumeration is information-dense rather than padding, though the sentence is somewhat crammed.

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 supplies the missing return-value context and a version requirement. It is nearly complete, with only the sibling disambiguation and any permission/read-only notes left 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 both parameters (site, doc) and the doc enum are already fully documented in the schema. The description adds no format or syntax detail about the parameters themselves, 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 ('Get a generated document's state') and enumerates what that state contains (active, library loaded, selection, sections written), which is far more informative than the name alone. It does not explicitly distinguish itself from close siblings like legal_get_document, legal_render_document, or legal_get_generator_library, so an agent must still infer the boundary.

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

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

The description implies read usage ('Get ... state') but never says when to call this versus legal_get_document, legal_get_generator_library, or legal_render_document. No exclusions or prerequisite workflow (e.g., after legal_put_generator) are given, leaving selection 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?

No annotations are provided, so the description carries the burden. It usefully discloses a version prerequisite (cvrt-legal 0.7.0+) and that the plugin ships no bundled texts, so an agent can anticipate an empty library. It does not describe the return shape or pagination, leaving gaps for a read tool with 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?

One tight sentence with a clarifying parenthetical, front-loaded with the action and resource. No filler, though the version constraint is crammed onto the end rather than 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?

For a simple two-param read with no output schema and no annotations, the description covers the resource, source path, and version requirement. It stops short of explaining what the returned library looks like or how the agent should consume it, leaving a modest gap.

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

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

Schema description coverage is 100%, so both params (site, doc) are already documented in the schema, including the enum values and BFSG note. The description adds only the general concept of a 'generated document', 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 ('Get the imported text library of a generated document') and clarifies the source of the texts. It does not explicitly distinguish itself from the sibling legal_put_generator_library, but the get/put pairing and the 'generated document' scope make the intent 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?

The description gives useful context (texts come from websites/bin/legal-v4/privacy, the plugin ships none, requires cvrt-legal 0.7.0+) which implies when the tool returns content versus nothing. However, it never states when to use this versus legal_get_generator or the other legal_get_* readers, so 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?

No annotations exist, so the description carries the full burden. It usefully discloses the meaning of each returned flag and a hard dependency (cvrt-legal 0.4.2+), which the schema does not. However, it never explicitly states this is a safe read-only operation or describes permission requirements, leaving a gap for a zero-annotation 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?

Three tight sentences, front-loaded with the resource and its return shape, then semantics, then the version prerequisite. No wasted text, though the middle clause about reachability/compliance is somewhat 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?

For a two-param read tool with no output schema, the description sensibly explains the returned values itself. Combined with full schema coverage, an agent has what it needs to call it correctly, even though auth/read-only behavior is left implicit.

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%: both 'site' and 'doc' carry descriptions and 'doc' has an enum, so the schema does the heavy lifting. The description adds no parameter syntax or format detail, making the baseline 3 correct.

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

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

States a specific verb+resource: getting the page a legal document is linked to, and enumerates the returned facts (linked, page_id, post status, ok). It is clearly distinguishable from the write-side sibling legal_link_page. It stops short of explicitly naming alternatives, so 4 rather than 5.

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

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

No when-to-use guidance or prerequisites for choosing this over legal_link_page or legal_get_document. The note that a document only 'counts as reachable' and legal_status turns compliant when ok is true is semantic context, not routing or exclusion criteria.

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

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

With no annotations, the description carries the full disclosure burden, and it does add one genuinely useful trait: secrets are returned as { set: boolean }, never raw. It stops short of covering auth requirements or the overall shape of the settings payload.

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

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

Two short sentences with zero filler; the masking behavior is front-loaded right after the purpose statement.

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

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

For a single-parameter read tool with no output schema, the description supplies the crucial return-value caveat about masked secrets. Only minor gaps remain, such as auth or scope expectations.

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

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

One parameter with 100% schema description coverage; the schema already explains 'site' and points to list_sites. The description adds nothing beyond that, so the baseline 3 applies.

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

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

States a specific verb+resource (get cvrt-legal settings), which is clearly distinguishable from siblings like legal_update_settings and legal_get_facts. The qualifier 'cvrt-legal' is slightly opaque but the operation itself is unambiguous.

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 indication of when to use this versus legal_update_settings, legal_get_facts, or legal_get_social, and no prerequisites or exclusions. The pairing with the settings-mutation sibling is only implied by the name.

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

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

With no annotations, the description carries the full burden. It discloses that this is a read (implied by 'Get'), describes the payload contents, and adds a real operational constraint — the cvrt-legal 0.6.0+ dependency. However it says nothing about permissions, pagination, or side effects, so coverage of behavioral traits is partial.

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

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

Two tight sentences, front-loaded with the action and resource, followed by the returned content and the version prerequisite. No filler or redundancy; every clause contributes.

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?

In the absence of an output schema, the description usefully enumerates the return shape (networks, enabled state, profile URLs, rendered preview) and states the plugin version dependency. For a one-parameter read tool this is largely complete, though it omits any mention of the site parameter or error/precondition behavior.

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

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

Schema description coverage is 100% for the single 'site' parameter (documented as 'Site id (see list_sites)'), so the baseline is 3. The description adds no additional semantics about the site argument, leaving the schema to do all 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?

States a specific verb ('Get') and a clearly scoped resource ('social-media section configurator'), then enumerates what it surfaces: networks on offer, which are enabled with their profile URLs, and the rendered preview. This is far more informative than a bare name restatement. It doesn't explicitly contrast with the similarly named sibling legal_get_social_modules, but the returned content makes the distinction inferable.

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

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

No explicit when-to-use or when-not-to-use guidance, and no named alternative (e.g., legal_put_social for writes, legal_get_social_modules for the module list). The stated version prerequisite ('Requires cvrt-legal 0.6.0+') is a useful precondition, which lifts it above a bare 2, but routing guidance 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. 'Get' implies read-only, and the cvrt-legal 0.6.0+ requirement is a genuine prerequisite, but there is no disclosure of permissions, what happens if no modules were imported, or the shape of the result.

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

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

Two short sentences, the purpose front-loaded and the version constraint following. Neither sentence is filler, though the version note is somewhat tangential to invoking 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?

A single-parameter read tool with a fully documented schema and no output schema, so explanation of return values is not required. Still, the description gives no sense of what a 'social module' contains or whether the result can be empty, leaving a small 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% – the single 'site' parameter is documented in the schema with a pointer to list_sites. 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+resource: 'Get the imported social-media text modules.' The qualifier 'imported' and 'text modules' distinguishes it from legal_get_social and legal_put_social_modules, though it never explicitly names 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?

There is no statement of when to use this tool versus the closely-named siblings (legal_get_social, legal_put_social_modules, legal_get_generator_library). The version prerequisite is useful but is not positive/negative usage 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?

No annotations are provided, so the description carries the full burden. It partially compensates by disclosing the shape of the returned theme data, but it never states that this is a read-only, non-mutating operation, nor whether the site must have a theme configured or what happens if none 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?

One sentence, front-loaded with verb and resource, and the return contents follow immediately. No filler, no redundancy.

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

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

There is no output schema, so the description must describe the return value — and it does, naming the three components of the theme payload. It is nearly complete for a single-parameter read tool; only the empty/unset-theme behavior and read-only nature are 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?

Schema description coverage is 100% — the single 'site' parameter is documented in-schema with the 'see list_sites' pointer. The description adds nothing about the parameter, so the baseline 3 applies; 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 (Get) and resource (banner theme) and enumerates the return payload — preset name, CSS custom-property overrides, rendered CSS — which is more than a restated name. It does not, however, distinguish itself from the adjacent wp_get_theme (WordPress theme) or legal_put_theme siblings, which is a real disambiguation risk in this namespace.

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

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

There is no when-to-use guidance, no statement that this is the read counterpart to legal_put_theme, and no note about when to prefer it over wp_get_theme. The agent must infer everything from the tool name alone.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses that content is written into post_content immediately and on every later save, the mirrored flag semantics, that the text persists after plugin deactivation, and the banner_linked side effect for impressum/datenschutz. It omits return/error behavior, keeping it from 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?

Front-loaded with purpose and scope, and every sentence carries operational detail. The nested parentheticals (mirrored, banner_linked) make it somewhat dense/run-on, so it is not maximally clean.

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 mutation tool with no annotations and no output schema, it covers the key risks an agent must know: write side effects, persistence, version prerequisite, and unlink semantics. Return value and failure modes are not described, leaving a small gap.

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

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

Schema description coverage is 100%, so the schema already documents doc, site, and page_id (including '0 to unlink'). The description reinforces the page_id=0 unlink behavior and the allowed document types, but adds little beyond the structured fields, 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?

States a specific verb and resource ('Link a legal document to its WordPress page') and immediately constrains scope ('post type page only; posts and products are refused'). This distinguishes it from generic page/mutation siblings such as wp_update_page and legality-rendering tools like legal_render_document.

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

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

Gives clear context (link a rendered legal document into a page) and important exclusions (only page post type; posts and products refused; page_id 0 unlinks; requires cvrt-legal 0.4.2+). It does not name an explicit alternative tool to use instead, 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?

No annotations are provided, so the description carries the full burden. It discloses the return shape (required/filled state, linked page), and the verb 'List' implies a read-only operation, but it does not state permissions, pagination, or whether any side effects occur.

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

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

A single front-loaded sentence with no wasted words. It puts the operation and resource first and then names the returned fields compactly.

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 list tool with no output schema, the description covers what the tool returns and implies its read-only nature. It omits pagination/ordering details and explicit permission requirements, but those are relatively minor for this scope.

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

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

The schema has 100% description coverage for the single 'site' parameter, including a reference to list_sites. The description adds no parameter-level meaning beyond that schema text, which is the baseline 3 when the schema already documents the parameter.

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

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

The description states a specific verb (List) and resource (legal document types) and adds scope (all) plus returned fields. It is clear enough to distinguish from legal_get_document and legal_put_document by plurality and operation, but it does not explicitly name the sibling tools it is not.

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

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

No when-to-use or when-not-to-use guidance is provided. An agent can infer that this is a listing operation, but there is no explicit routing against alternatives such as legal_get_document or legal_status.

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 merge semantics for omitted keys, the side effect of rewriting a generated Datenschutz section when enabled changes, the return value, and a minimum version requirement. It still omits permissions/auth needs and reversibility details, so it falls 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 description is dense but well structured: purpose first, then merge behavior, side effects, return value, and compatibility. Every sentence adds distinct operational information without 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 9-parameter mutation tool with nested objects and no output schema, the description covers the important behavioral contract: merge semantics, side effects, return value, and version. It could be more complete by clarifying when to use this versus legal_get_accessibility and whether permissions are required.

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 78% and the schema documents most parameters well, so the baseline is around 3. The description adds meaningful semantics beyond the schema by explaining that omitted keys retain their values and tying 'enabled' to an automatic document rewrite.

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

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

The description states a clear verb (Configure) and resource (self-hosted accessibility tool) and clarifies what it replaces. It is distinct from the sibling getter by name, but does not explicitly name legal_get_accessibility as the read counterpart.

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 update/config usage through 'Configure' and gives merge behavior, but it does not state when to use this tool instead of legal_get_accessibility or other legal_* settings tools. Version guidance is present, but no explicit alternatives or exclusions.

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

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

With no annotations, the description carries the full disclosure burden. It does add real behavioral context: nothing is sent to the browser until the visitor accepts, and the plugin gates all three trackers. But it omits what an agent most needs for a config-overwriting 'put' tool — whether existing settings are replaced or merged, and any 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?

Three front-loaded sentences with no wasted preamble, and the key scoping fact (consent gate) leads. The closing clause is slightly rhetorical ('precisely because it owns the gate'), but it still carries routing information about the SEO exclusion.

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 9-parameter config tool with no output schema and no annotations, the description and high-coverage schema together cover purpose, scope and gating behavior well. The remaining gap is mutation semantics (overwrite vs merge, revert behavior), which is a modest shortfall rather than a blocking 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 89%, so the schema already documents nearly every parameter with rich detail (gating caveats for ahrefs_key, the gtm_id/ga4_id double-count rule, the Datenschutz precondition for log_enabled). The prose only refers to GTM/GA4/Ahrefs generically and adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Configure the consent banner and every tracking credential the site uses') and scopes it to what the plugin owns: GTM, GA4, Ahrefs. It also explicitly disclaims the SEO verification meta tags, naming the sibling namespace that owns them, so an agent can tell it apart from cvrt-seo-manager tools without opening a 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 description gives a clear boundary ('search-engine verification meta tags are NOT here; those belong to cvrt-seo-manager') which routes the agent away from a wrong tool. However, it gives no guidance on when to choose this over adjacent legal_* siblings such as legal_update_settings or legal_put_facts, or what prerequisites exist before calling.

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 "Replace" does signal an overwrite of the whole document. It adds one genuinely useful behavioral fact - the plugin ships no legal prose and only stores/renders supplied content - but omits what happens to existing sections, permission requirements, or reversibility.

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 then the key structural rules. Nothing is padded, though the closing note about the plugin not shipping prose is slightly peripheral and could be folded into the first sentence.

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 destructive, no-annotation, no-output-schema write tool, the definition covers structure semantics and the lack of default content, but does not clarify whether the replacement is total (wiping omitted sections) or whether the target document must already exist - important for a PUT-style operation.

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 four parameters, including the slug derivation rule and ordered sections. The description restates the ordering and slug-derivation semantics rather than adding new syntax or constraint detail, 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?

"Replace a legal document" gives a specific verb and resource, and the concept of whole-document replacement is distinguishable from the sibling section-level tools (legal_add_section, legal_update_section). However, it never names those siblings or explicitly contrasts the full-document write against partial edits, so the differentiation is implicit 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?

There is no when-to-use or when-not-to-use guidance. An agent must infer from the verb "Replace" that this overwrites an entire document and that section-level siblings exist for partial edits; no prerequisites, no conditions, and no alternatives are named.

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

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

With no annotations, the description carries the full burden and does so well: it discloses merge semantics ('only the keys given change'), a clear-field side effect ('empty string clears a field'), a broad side effect ('regenerates every generated document'), and a version requirement. Missing only permissions/auth and reversibility nuance, which keeps it from 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 terse sentences, front-loaded with the purpose, then behavior, then the version constraint. Zero padding; 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 mutation tool with no annotations and no output schema, the description covers the critical unknowns: what changes, the clearing convention, and the document-regeneration side effect. Lacking any statement about permissions or failure modes, but otherwise complete enough to 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 100%, so the baseline is 3, but the description adds real meaning beyond the schema for the 'facts' object: the merge contract and the empty-string-clears convention are not stated in the schema. That elevates it above baseline.

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