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

With no annotations, the description carries the full burden and largely meets it: it discloses the auth prerequisite, the side effect that the new account becomes active, the downstream impact on projects_create/projects_list, and the return shape (id and name). It stops short of error/failure behavior (duplicate name or email, permission errors), which is the remaining gap for a mutating 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?

Five short sentences, each carrying unique information: purpose, auth prerequisite, side effect, return value, and alternative. The most decision-relevant constraints (login, already-have-an-account) are front-loaded rather than buried.

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 create tool with no annotations and no output schema, the description covers purpose, auth, side effects, return values, and the alternative tool. An agent has everything needed to decide whether and how to call 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 description coverage is 100%, so name, email, and currency are already fully documented including the non-changeable currency constraint. The description adds no parameter-level meaning beyond the schema, 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 and resource ('Create a new billing account (organization)') plus what the resource holds ('projects and payment details'). This clearly separates it from siblings like accounts_list and accounts_use 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?

Explicitly names prerequisites ('Requires a prior platform login (use the login tool first)') and an alternative workflow ('Most users need only one account — call accounts_list first to check whether a suitable one already exists'). Both the when-to-use and the anti-pattern are given.

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

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

With no annotations, the description must carry the behavioral burden, and it discloses the auth requirement, the returned field set including status enum values (Active/Suspended/Canceled), and which account is flagged active. It omits pagination, ordering, and error behavior, keeping it below 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 dense sentences that are front-loaded with the primary action, then prerequisites, then return/next-step guidance. Every sentence earns its place with 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?

For a no-parameter list tool with no output schema and no annotations, the description covers purpose, auth prerequisite, return values, and the follow-up tool, which is everything an agent needs 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?

Zero parameters, so the baseline is 4 per the rubric. The empty schema leaves nothing for the description to clarify about inputs, and it correctly focuses on the (absent) output shape instead.

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 (billing accounts / organizations) plus the scope restriction ('the logged-in user belongs to'). It is clearly distinct from siblings like accounts_create and accounts_use.

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?

Explicitly gives a prerequisite ('Requires a prior platform login — use the login tool first') and a downstream action ('pick one with accounts_use before creating or listing projects'). Names both the alternative tool and the condition that selects 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 burden and does well: it discloses a state mutation, the prerequisite, accepted input forms, and the failure mode ('error if no account matches'). It does not state whether the selection persists across sessions or how it interacts with a previously set account, leaving 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?

Three sentences, front-loaded with the core action, then prerequisites/dependents, then input and return behavior. 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?

There is no output schema, so the description supplies the return contract (resolved account name and id, or an error). Combined with the single documented parameter and explicit prerequisites, nothing needed to call it correctly is missing.

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

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

Schema coverage is 100% and the schema description already explains the UUID-or-prefix format and points to 'accounts_list'. The description repeats this rather than adding new semantics, 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 ('Set the active billing account that project commands operate on'), and the scope clause distinguishes it from the accounts_* and projects_* siblings. An agent can tell it selects context rather than creating/listing accounts.

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

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

Gives an explicit prerequisite ('after login'), a conditional ('when you belong to more than one account'), and downstream tools that depend on it ('projects_list', 'projects_create', 'projects_use'). It also names the alternative for discovering valid ids ('accounts_list').

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful scope context (that the listing includes both platform routes and dynamically generated entity routes), which is not derivable from the annotations, but says nothing about pagination, output shape, or auth needs.

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 an efficient parenthetical; no filler. Slightly cryptic on its own but appropriately sized for a simple list command.

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

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

For a read-only discovery tool with one optional param and no output schema, the description covers what is listed but not the form of the results or any scoping behavior (e.g. whether entity routes require prior entity definitions). Adequate but with a clear 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?

With only one optional parameter at 100% schema coverage, the schema already documents base_url fully. The description adds no extra meaning about when or why to override the base URL, 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 (List) and resource (API endpoints), and the parenthetical 'platform + dynamically generated entity routes' gives real scope. The generic tool name 'api' is rescued by the description, though it does not explicitly distinguish itself from near-neighbors like docs, cli, or fetch.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as docs or cli for discovering the API surface. The agent must infer usage from the verb alone.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so safety is covered. The description then adds the one genuinely non-obvious behavioral fact: the raw key is returned once and can never be retrieved again, which tells the agent the response value must be captured immediately rather than re-fetched.

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

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

Two short sentences, front-loaded with the action and followed by the highest-value warning. No filler, no restatement of the title.

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 100% schema coverage for all five parameters and no output schema, the description is nearly self-sufficient for invocation; the one-time-secret note covers the biggest return-value risk. It could go slightly further by noting that save_as suppresses the printed key, tying the parameter to that 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%, so all five parameters (name, save_as, expires_in, permissions, no_expiry_cap) are already fully documented in the schema. The description adds no extra semantics about defaults, formats, or interactions, 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 (Create) and resource (an API key), which unambiguously separates it from api_keys_list and api_keys_revoke. It stops short of naming those siblings, so an agent still infers the boundary from the tool name rather than the prose.

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, no prerequisites (e.g. required role or scope), and no mention of alternatives such as reusing an existing key via api_keys_list. It is a bare imperative with no routing information.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the 'current user' scoping constraint, but says nothing about pagination, ordering, or whether key secrets are redacted, which are the behaviors an agent would actually wonder about here.

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 seven-word sentence with the scope constraint front-loaded and no filler. Every word 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 zero-parameter read-only list tool with no output schema, the description is nearly sufficient. The one open question it leaves is what a listed key object contains (notably whether the secret value is included), which for API-key tooling is material but not essential to 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?

The tool takes zero parameters, so the baseline of 4 applies; there is no parameter syntax the description needs to compensate for. Nothing in the description is required to clarify inputs.

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

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

States a specific verb (list) and resource (API keys) plus the scope qualifier 'for the current user', so the agent knows exactly what is returned. It distinguishes itself from siblings like api_keys_create and api_keys_revoke by verb alone, but never names them or explicitly rules out listing other users' keys.

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 verb and scope; there is no statement of when to call this versus api_keys_create or api_keys_revoke, nor any prerequisite or exclusion. The self-evident read operation keeps it from scoring lower, but no explicit routing guidance is provided.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known without the description. However, the description itself adds no behavioral context such as whether revocation is permanent, whether it takes effect immediately, or what happens to in-flight requests using the key.

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 that is front-loaded with the action and resource. There is no filler, though it is close to the minimum viable length rather than a tightly optimized definition.

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

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

For a one-parameter destructive tool with annotations covering the safety profile, the description is functionally adequate. It still omits any note about irreversibility, idempotency, or error behavior, which would matter for a destructive 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?

Only one parameter exists and schema description coverage is 100% ('API key ID to revoke'), so the schema fully documents it. The phrase 'by ID' in the description adds nothing beyond that baseline, warranting the standard 3.

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

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

The description gives a specific verb (revoke) and resource (an API key) with the identifying dimension (by ID), so it is unmistakable against siblings like api_keys_list or api_keys_create. It does not explicitly name or contrast those siblings, keeping it short of a 5.

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

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

There is no guidance on when to use this tool versus api_keys_list or api_keys_create, no prerequisites, and no note about irreversibility or preconditions such as key state. The agent must infer all context from the name alone.

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

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

No annotations are provided, so the description carries the full burden. It discloses that output is returned, that destructive commands may prompt unless '--yes' is added, and that '--json' is available for machine-readable output. It does not cover authentication, error handling, or general side effects, but does more than the minimum.

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

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

Four compact sentences with zero waste. It front-loads the core purpose and fallback role, then adds examples and flag guidance in a logical order.

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 generic CLI wrapper with no output schema and no annotations, this covers the main selection and invocation concerns. It could be slightly more complete about error behavior or permission requirements, but the essential information 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?

The single command parameter is fully described in the schema, so baseline is 3. The description adds useful flag semantics beyond the schema, especially '--yes' for skipping confirmation prompts and '--json' for machine-readable output, plus concrete examples of command formatting.

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

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

States a specific verb and resource ('Run any Anythink CLI command') and explicitly routes the agent away from dedicated tools toward this fallback. The scope and intended use are unambiguous even against a large sibling set.

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

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

Gives explicit when-to-use guidance ('Prefer the dedicated tools; use this for anything they don't cover') and operational instructions like adding '--yes' for destructive commands and '--json' where supported. No inference is needed to select this tool correctly.

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 does so well: it discloses the exact scope of destruction (local credentials and settings only), clarifies what is NOT affected (server-side project, tokens), and specifies the return behavior ('confirmation, or a not-found message'). This is materially more than the schema conveys.

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 tightly packed sentences, front-loaded with the action and scope, then the boundary condition, then the discovery hint and return behavior. 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 single-parameter local mutation with no annotations and no output schema, the description covers everything an agent needs: scope of deletion, exclusion of server-side effects, the sibling alternative, the prerequisite for valid names, and the return outcome. Nothing is missing.

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

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

Schema coverage is 100%, so the single 'profile' parameter is already fully documented, including the config_show pointer. The description adds no syntax 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 and resource ('Delete a saved project profile from the local CLI configuration') with the scoping qualifier 'local' front-loaded. The agent can immediately distinguish this from server-side siblings like projects_delete. No ambiguity about what is being removed.

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?

Explicitly delineates when-not-to-use ('does not delete the project or revoke tokens server-side') and names the alternative tool ('to remove the project itself, use projects_delete'). It also provides the prerequisite discovery step ('Run config_show to see profile names'). Fully self-routing.

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

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

No annotations are provided, so the description carries the full burden — and it discloses 'Reads local config only — makes no network calls', which tells the agent this is a side-effect-free local read with no auth/network prerequisites. It also enumerates the returned fields. It stops short of stating whether anything is cached or mutated locally, so it is strong but not exhaustive.

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 purpose, then return contents, then usage routing, then a behavioral caveat. Every sentence adds information an agent needs; nothing is repeated from structured fields.

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

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

There is no output schema, so the description compensates by enumerating the response shape for both profiles (name, org id, auth method, alias, platform) and platforms (URLs, billing account, login status). Combined with the usage routing and the no-network disclosure, an agent has everything required 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?

Zero parameters, so the baseline is 4; there is nothing for the description to clarify beyond what an empty schema already communicates.

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 ('Show the local CLI configuration') and precisely delineates scope: all saved project profiles and platform logins plus which is active. An agent can distinguish it from config_use, config_remove, and logout 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?

Explicitly names what to use it for: discovering profile names for 'config_use', 'config_remove', or 'logout', and checking which project the 'cli' tool targets. That is concrete when-to-use routing plus named alternatives.

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

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

No annotations are provided, so the description carries the burden; it discloses that this mutates global state (which profile cli operates against), that no re-authentication is needed, and the error behavior when the profile is absent. It does not describe whether the switch is persistent across sessions or reversible, 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?

Front-loads the core action, then prerequisites, then return behavior in four tight sentences with no filler. Slightly overlaps with the schema's parameter note 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?

For a one-parameter state-switching tool with no annotations and no output schema, the description supplies prerequisite, discovery path, no-reauth behavior, and return semantics. Everything an agent needs to call it correctly 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% and the single parameter's schema description already tells the agent to consult 'config_show' for valid names. The description largely repeats that guidance rather than adding format or constraint 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 (Switch) and resource (active project profile), and scopes the effect to the 'cli' tool's commands. An agent can distinguish it from config_show (read), config_remove (delete), and projects_use without opening schemas.

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?

Explicitly says to use it 'to move between already-connected projects without re-authenticating', states the prerequisite that the profile must already exist (created by 'projects_use' or 'login_direct'), and routes to 'config_show' for discovery of valid names. Both the when and the alternative are named.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the write/safe profile is covered. The description adds nothing beyond that: no conflict/duplicate behavior, no validation expectations, no note that partial or malformed JSON data will fail.

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

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

Four words with no waste, but this is under-specification rather than conciseness — the single sentence conveys no information an agent could not get from the tool name and annotations.

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

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

For a write tool taking an entity name plus a free-form JSON payload, the description should say something about entity semantics, required field values, or the shape of a successful result. None of that is present, and there is no output schema to fill 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%, with both `entity` and `data` documented (including a JSON example), so the schema carries the parameter burden. The description contributes zero additional meaning, which is the baseline expectation when coverage is complete.

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?

"Create a new record" essentially restates the tool name (data_create) with no differentiating detail. Among siblings like entities_create, accounts_create, projects_create, and data_update, an agent cannot tell what "record" means here or which collection this writes to.

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 alternative creation tools such as entities_create or accounts_create. The agent must infer everything from the name alone.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is disclosed structurally. The description adds nothing on top: it does not say whether the delete is hard or soft, whether it cascades to related records, whether it is reversible, or what permissions are needed. With annotations carrying the safety burden the bar is lower, but the description contributes zero extra behavior.

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

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

The three-word fragment is not concise so much as under-specified; it is front-loaded but contains no informational payload. As with a bare single-word description, brevity here reflects omission rather than efficiency.

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 output schema, the definition omits effect scope, recoverability, and permission requirements. The annotations cover the destructive flag, but an agent still lacks the context needed to call this safely, and the low parameter count does not excuse 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%, so both parameters (id, entity) are documented in the schema itself. The description adds no syntax, format, or scoping detail beyond that, which lands squarely on the baseline of 3 for a fully covered schema.

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

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

The description "Delete a record" essentially restates the tool name (data_delete) and title (Data: delete) with a generic resource noun. It gives no way to distinguish this from the many sibling delete tools (entities_delete, fields_delete, files_delete, secrets_delete, users_delete) or from data_get/data_create/data_update. This is tautological rather than differentiating.

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, no exclusions, and no mention of any alternative tool. An agent cannot infer from the text when data_delete is the right choice versus entities_delete or files_delete.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds no further behavioral details—such as permissions, error behavior when the ID is absent, or pagination—so it remains minimum viable without contradicting annotations.

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

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

It is a single front-loaded sentence with no filler, which is appropriately brief for a simple lookup. It wastes nothing, though it is so terse that structure adds little 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 a fully documented schema, the description is serviceable but leaves the required entity argument entirely to the schema and gives no routing hints among sibling data_* tools. It is minimally complete, not comprehensive.

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 'entity' and 'id' are documented in the schema. The description only alludes to the ID parameter and does not add meaning beyond the schema, 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 ('Get') and resource ('single record') plus scoping ('by ID'), which is clear. It doesn't explicitly name the required 'entity' parameter or distinguish itself from data_list/search_query, so sibling differentiation is only implied.

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

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

There is no guidance on when to use this instead of data_list, data_create, or data_update, nor any prerequisites. The 'by ID' clause implies a known ID is needed, but that is the extent of usage 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds nothing further – no mention of pagination defaults, the streaming 'all' behavior, or filter semantics, despite these being non-obvious traits of the tool.

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

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

The single phrase is front-loaded and wastes no words, but for a tool with filtering, pagination, and streaming options it is under-specified rather than genuinely concise. It reads as a title restated rather than a deliberate one-line summary.

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 100% schema coverage and readOnly annotations, the structured fields carry most of the burden and no output schema is needed. The gap is routing: nothing tells the agent how this list operation relates to data_get, search_query, or entities_list, which the description should ideally address.

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

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

Schema description coverage is 100%, so all five parameters (including filter syntax and pagination) are documented in the schema itself. The description only echoes the 'entity' parameter ('in an entity') and adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb ('List') and resource ('records in an entity'), so the operation is immediately understandable. However, it offers no differentiation from sibling read tools like data_get, search_query, or entities_list, leaving the agent to infer scope from the name alone.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as data_get (single record) or search_query (filtered queries), nor any stated prerequisites. Usage is only implied by the word 'List'.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is partly covered. The description adds only the vague 'view or set' dual-mode and says nothing about what 'set' destroys (existing access grants), whether it replaces or appends, or what the response looks like — a meaningful gap for a tool flagged destructive.

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

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

A single short sentence with the resource front-loaded and no filler. Nothing to trim.

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, dual-mode tool with no output schema and four parameters, the description is too thin: it never explains how view vs set is triggered (presumably the presence of `user`), nor the effect of `readonly`, nor what happens to existing access. An agent would have to guess before invoking a destructive 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%, with each of the four parameters (id, user, entity, readonly) fully documented in the schema itself. The description adds no format, default, or interaction detail beyond the schema, so the 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 pair (view/set) and resource (RLS user access) scoped to a record, so it is distinguishable from data_get/data_update siblings. However, the dual-mode 'view or set' is never resolved — the description doesn't say which input selects which mode, leaving the actual operation ambiguous.

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 conditions, and no reference to alternatives such as data_update or roles_permissions_add. An agent cannot tell from the description whether this is the right tool for granting a user access versus some other permission mechanism.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is partially covered. The description adds nothing on top: it does not say whether unspecified fields are preserved or cleared, whether the entity must already exist, or what happens on an unknown id — all critical for a destructive 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?

Three words with zero waste, but this is under-specification rather than conciseness. Nothing is front-loaded because there is nothing to front-load; the description fails to earn its place by omitting anything actionable.

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, non-classified mutation tool with no output schema, the description should at least state the replace-vs-merge behavior and failure modes. The annotations cover only the destructive flag, leaving the description materially incomplete for an agent deciding how to build the update payload.

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% (id, entity, data are all documented inline), so the baseline is 3. The description adds no meaning beyond the schema — it does not explain the entity namespace or the JSON field semantics of "data" — but the schema itself carries the parameter documentation adequately.

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

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

"Update a record" essentially restates the tool name and title (data_update / "Data: update") without adding scope, entity type, or any distinction from siblings like data_create, data_get, data_delete, or data_list. It is a verb+resource, but so generic that an agent cannot tell what a "record" is here or how this differs from entities_update or fields_update.

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 named alternative (e.g., entities_update vs data_update vs fields_update). The only implied usage is the generic CRUD inference that "update" means modify an existing record, which the name already conveyed.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that output is a CLI reference in markdown or JSON form, which is useful context, but it discloses little beyond the annotation-covered safety trait.

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

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

A single front-loaded sentence with zero filler; the verb and resource come first and the output-format detail follows 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 read-only documentation tool with annotation coverage and no output schema, the description is essentially complete. The only loose end is what the '--json' invocation means for a zero-parameter MCP tool, which is left 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?

The tool takes 0 parameters, so the baseline is 4 and the schema cannot be enriched further. The description mentions a '--json' option that the empty schema does not expose, which is a slight mismatch but does not mislead about any actual 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 and resource ('Print the full CLI reference'), so an agent immediately knows the outcome. However, it does not differentiate itself from the sibling 'cli' tool (or 'api'), leaving ambiguity about which reference-listing tool to pick.

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

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

The parenthetical 'markdown or --json for AI/tooling consumption' hints at intended consumption modes, but there is no explicit when-to-use, when-not-to-use, or alternative-tool guidance relative to siblings like 'cli' and 'api'.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds no behavioral context beyond restating the operation, such as authorization requirements, uniqueness constraints, or side effects of creating an entity.

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 redundancy. It is appropriately concise for the purpose statement, though its brevity leaves other useful information absent.

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 five-parameter creation tool with no output schema, the description does not explain what an entity is, when to create one, or how it relates to sibling creation tools. Annotations and schema cover safety and parameters, but the description is too thin to ensure correct selection among the many create-like siblings.

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

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

Schema description coverage is 100%, so every parameter is already documented in the input schema. The description adds no parameter-level meaning, which is acceptable at the baseline of 3 when the schema fully does that job.

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 and resource: 'Create a new entity'. This distinguishes it from non-create entity siblings like entities_get or entities_delete, but it does not differentiate it from other create-style tools such as data_create or accounts_create. It is clear but lacks sibling-specific context.

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

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

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of any related tools. The agent is left to infer usage entirely from the name and schema.

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

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

The annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description usefully adds that all entity data is removed, but it says nothing about irreversibility, required permissions, or confirmation needs. It adds one meaningful detail beyond the annotations, not rich 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 front-loaded sentence with zero filler. For a one-parameter destructive tool, this is appropriately sized and easy to parse.

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 one required parameter, full schema coverage, and annotations carrying the destructive safety signal, the description is largely complete: it states the action and the cascade scope. A brief note on permanence or permissions would make it fully self-sufficient.

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

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

The single parameter has 100% schema description coverage ('Entity name to delete'), so the schema already does the heavy lifting. The description adds no naming format, ID-vs-name distinction, or other parameter nuance beyond the schema.

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

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

The description states a specific verb ('Delete') and resource ('an entity') and adds the important scope 'all its data', which separates it from entities_get, entities_update, and entities_create. It does not explicitly route the agent away from siblings like data_delete or fields_delete, 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 when-to-use guidance, no exclusions, and no named alternatives. The agent must infer that this tool is for deleting an entity rather than updating, creating, or deleting related resources; the description offers no selection help.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds only 'details and fields', which hints at the payload but discloses nothing about lookup failure behavior, name matching semantics, or permissions beyond what the annotations already imply.

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?

Six words, front-loaded with the verb and resource, with no filler. It is efficient, though the terseness edges toward under-specification rather than optimal information density.

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

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

For a one-parameter read tool with annotations covering safety, this is minimally adequate; there is no output schema, so the description could reasonably note whether the returned fields include related field definitions, but the omission is not fatal.

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 required parameter with 100% schema description coverage ('Entity name'), so the schema does the work. The description adds no extra meaning such as accepted name formats or case sensitivity, so the baseline 3 applies.

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

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

States a specific verb (get) and resource (entity) plus what is returned (details and fields), which is enough to know it is a single-record read. However, it does not differentiate from close siblings such as entities_list, entities_update, or fields_get, so an agent must inspect the schemas 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?

No when-to-use guidance, no prerequisites, and no named alternative. The description never says to prefer this over entities_list when fetching one known entity, nor what happens when the name does not resolve.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The word 'all' adds a small amount of scope information (no filtering applied), but the description says nothing about pagination limits, result size, or ordering, which matters for a list 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?

Three words with zero waste and the scope constraint front-loaded. It is arguably terse for a list tool, but nothing in the sentence is filler or redundant.

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

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

For a zero-parameter read tool the definition is nearly complete, but there is no output schema, so the description could reasonably state what is returned (entity identifiers, pagination behavior). That gap keeps it at a minimum-viable level.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There are no parameter semantics for the description to clarify or omit.

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 (entities), and the scope word 'all' distinguishes it from entities_get, which retrieves a single entity. It is clear but offers no further differentiation from siblings such as entities_create/update/delete beyond the verb itself.

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

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

There is no guidance on when to use this tool versus entities_get, entities_list-style searches, or other list siblings, and no mention of prerequisites. The agent must infer usage from the name alone.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the agent knows this is a destructive write operation. The description adds no behavioral context beyond that—it does not explain what gets modified, whether changes are reversible, required permissions, or side effects. With annotations covering the safety profile, it still fails to add useful behavioral 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 description is extremely concise, which would normally be positive, but for a destructive 4-parameter update tool the brevity leaves important specification gaps. It is front-loaded but under-specified rather than efficiently scoped.

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 update tool with no output schema, the description should provide more context about what settings are updated, how the required name parameter is used, and any safety or permission implications. Annotations and schema help, but the description itself is too thin to be 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%, and the schema itself documents each parameter clearly (rls, name, public, lock_records). The description adds no meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The verb 'update' and resource 'entity' are clear, but 'settings' is vague and does not distinguish this tool from siblings like entities_create, entities_get, or entities_delete. An agent knows it updates entities, but not which settings or how it differs operationally from other entity tools.

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

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

The description gives no guidance on when to use this tool versus alternatives such as entities_create or entities_delete, nor any prerequisites or exclusions. It states only what the tool does, leaving usage context to inference.

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

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

Annotations declare readOnlyHint=false and destructiveHint=true, but the description neither confirms nor contradicts this, and it omits crucial context: which HTTP methods are permitted, whether arbitrary paths are allowed, what authentication scopes apply, whether side effects can occur, and whether the tool is rate-limited. For a tool that can mutate the active project, this is a large 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?

The description is a single short sentence, front-loaded and without waste. It is efficient, though its brevity comes at the cost of completeness rather than being optimally 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 destructive, open-ended API request tool with a rich parameter set and no output schema, the description is severely lacking. It should explain the permissible scope (which APIs), method restrictions, authentication behavior, and any safety warnings. With no output schema, the description also fails to indicate the structure of the response.

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 all three parameters (body, path, method) are documented in the schema with examples. The description adds no additional semantics beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description states a generic verb-resource pair ("Make an authenticated API request to the active project") but is essentially a raw HTTP escape hatch that could be confused with many siblings like api, cli, or integrations_execute. It does not specify what resources are reachable, what the response looks like, or how it differs from a direct API tool. It restates the tool's nature rather than carving out a distinct purpose.

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, when-not-to-use, or alternative guidance. With ~90 siblings including api, cli, and many resource-specific tools, an agent has no way to know whether to call fetch or a dedicated tool. This is a serious omission.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the mutation/safety profile is minimally covered. The description adds nothing beyond that: it does not state required permissions, whether field names must be unique, side effects on existing data, or which parameter combinations are valid for relationship 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?

A single short sentence with the verb front-loaded and no filler. It earns its brevity, though the size is arguably too small for a 17-parameter mutation tool rather than an issue of wasted words.

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

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

For a tool with 17 parameters, no output schema, and only minimal annotations, the description leaves critical structure unexplained – notably that the chosen type determines which other parameters (target, options, display, on_delete) become relevant. An agent calling this correctly needs far more context than one sentence provides.

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% across all 17 parameters, so the schema already documents types, defaults, and enum-like value lists. The description contributes no additional parameter meaning, which matches the baseline 3 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?

"Add a field to an entity" gives a verb (add) and a resource (field), but it is essentially a restatement of the tool name/title "Fields: add" with no clarifying detail. It does not identify what kind of field, what an entity is in this domain, or how it differs from siblings like fields_update, fields_delete, or fields_get beyond the bare 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as fields_update for modifying an existing field or entities_create for creating the entity first. The agent must infer everything from the verb alone.

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

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

The annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds only the 'from an entity' scoping and says nothing about permanence, whether stored field values are destroyed, or what permissions are required for a destructive schema change.

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

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

A single front-loaded sentence with zero filler, correctly sized for a two-parameter tool. It is arguably over-terse for a destructive operation, but nothing is wasted or buried.

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 schema mutation with no output schema, an agent still lacks the consequences of deletion (data loss, reversibility), any required preconditions, and confirmation of what happens to existing records. The annotations signal destructiveness but the description does not contextualize 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 description coverage is 100% with both required parameters documented ('Entity name', 'Field name'), so the baseline is 3. The description reinforces that field_name is scoped to entity but adds no format, naming-convention, or validation 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 ('Delete a field') and scopes it with 'from an entity', which implicitly separates it from entities_delete and data_delete. It does not, however, name or differentiate against the close siblings fields_add, fields_update, fields_get, and fields_list, so the agent must infer the routing from the noun alone.

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

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

There is no when-to-use, when-not-to-use, or alternative guidance. An agent is not told when to remove a field versus updating it, nor whether prerequisites (empty field, admin role, schema not in use) apply before deletion.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds one useful content-scope fact, that relationship configuration is included in the returned definition, but says nothing about failure cases (unknown entity/field) or any auth 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?

A single sentence with zero filler, and the scope-defining phrase ('one field') plus the differentiating detail ('including relationship config') are both front-loaded.

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

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

For a simple two-parameter read tool whose schema and annotations are fully populated, the description is adequate; the extra note about relationship config is the main value-add. It would be complete if it hinted at what happens when the field or entity does not exist.

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 two documented string parameters, so the baseline is 3. The description adds no syntax, naming-convention, or format detail for entity or field_name 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 concrete verb+resource ('Get the full definition of one field') and scopes it to a single field, which implicitly separates it from fields_list. It also flags that the payload includes relationship config, so the agent knows this is the deep-detail read rather than a summary. It stops short of naming siblings 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as fields_list or entities_get. The agent must infer that 'one field' means use this instead of the list tool.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds nothing beyond that: no return format, pagination behavior, or permission context is provided, so it does not enrich behavioral understanding.

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 fragment with zero waste. It is appropriately compact for a trivial read tool, though its extreme brevity leaves no room for any supplementary context.

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 low-complexity, single-parameter list operation with annotations covering safety, the description is minimally adequate. However, with no output schema and no mention of return shape (list of field objects) or pagination, an agent lacks some context it might reasonably need.

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 'entity' parameter is fully documented in the schema. The description adds no syntax, format, or constraint details beyond what the schema already provides; baseline 3 is appropriate.

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

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

The description states a clear verb ('List') and resource ('fields') plus scope ('on an entity'), so the core operation is unambiguous. It does not, however, explicitly distinguish itself from close siblings like fields_get or fields_update; the distinction is left to the tool name alone.

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

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

There is no guidance on when to use this tool versus alternatives such as fields_get for a single field or fields_add/update/delete. The only implied usage is the tautological 'list fields when you want to list fields,' which is not actionable routing guidance.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false. The description adds only that an existing field is updated, with no disclosure of partial-update semantics, side effects, authentication needs, or how conflicting paired flags (public/no_public, indexed/no_indexed) are handled.

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

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

The description is a single, front-loaded sentence with no wasted words. It is appropriately concise, though its extreme brevity leaves no room for structure around the operation's complexity.

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?

Annotations cover the safety profile and the schema fully documents all parameters, so the description need not repeat those. However, for a 17-parameter destructive mutation, it omits update semantics such as partial updates and how the paired 'no_' flags interact, leaving a clear 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 all 17 parameters are thoroughly documented in the schema. The description adds no additional parameter meaning, making the baseline of 3 appropriate when the schema carries the full burden.

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 'properties of an existing field'. It distinguishes from sibling operations like fields_add and fields_delete by scoping the action to an existing field, though it does not explicitly name those alternatives.

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

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

No guidance is given on when to use this tool versus alternatives such as fields_add, fields_delete, or fields_get. There are no prerequisites, exclusions, or conditions for use.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the dangerous nature is conveyed structurally. The description adds nothing beyond that — no statement about irreversibility, whether deletion is soft or hard, or what happens to referencing entities.

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

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

One short, front-loaded sentence with zero padding or redundancy. It is appropriately terse for a single-parameter tool, though the brevity borders on under-specification for a destructive 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 destructive, irreversible operation with no output schema, the description omits anything an agent would want before calling it: confirmation requirements, whether deletion cascades, or how the ID is discovered. The annotations cover the safety flag but not the operational consequences.

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 a single parameter that is fully documented ('File ID to delete'), so the schema carries the semantics. The description's 'by ID' adds no format or source detail beyond what the schema states, matching the baseline of 3.

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

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

States a specific verb and resource ('Delete a file') plus the keying mechanism ('by ID'), which is unambiguous. It does not distinguish itself from siblings like files_get, files_list, or files_upload, but the operation itself is 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?

There is no guidance on when to use this versus alternatives, no prerequisite conditions, and no mention of how to obtain the ID (e.g., via files_list or files_get). The agent must infer the full workflow from sibling names.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that the operation returns metadata (rather than file content), which is useful context beyond annotations, but it does not describe error handling, authentication requirements, or return format details.

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

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

A single six-word sentence, front-loaded with the verb and resource. Every word earns its place; there is no redundancy or filler.

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

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

The tool is simple and the input schema is fully documented, but there is no output schema. The description does not explain what metadata fields are returned or how errors are handled, leaving the agent to guess the response shape. Adequate but with a clear gap.

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

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

Schema description coverage is 100%, and the single parameter 'id' is documented as 'File ID'. The description's 'by ID' adds no syntax or format detail beyond what the schema provides. Baseline 3 is correct 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 ('Get') and resource ('file metadata') with a scoping qualifier ('by ID'), making it distinct from sibling operations like files_list, files_upload, and files_delete. However, it does not explicitly name any sibling or state what the tool is not, 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 when-to-use guidance, alternatives, or prerequisites are provided. The description only states the action, leaving the agent to infer that it should be used when a file ID is known, with no explicit routing to or away from sibling tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that — no mention of pagination behavior, ordering, or what fields appear in the returned file records.

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 three-word phrase with zero wasted words and the verb front-loaded. Nothing to trim; fully efficient for what it attempts to convey.

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 paginated list tool with fully documented params and safety annotations, the description is barely sufficient. It omits pagination awareness and any distinction from the other files_* siblings, leaving gaps an agent would have to resolve from the schema 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 description coverage is 100% with two optional pagination parameters (page, limit) already documented with defaults, so the schema carries the parameter burden. The description adds no format, range, or semantics beyond what the schema provides, matching the baseline 3.

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

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

States a clear verb (list) and resource (uploaded files), so the agent knows the operation. However, it does not differentiate from siblings like files_get or files_delete, nor does it describe scope (all files? paginated set?), which keeps it below 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 indication of when to use this versus files_get, files_delete, or files_upload. There is no conditional guidance, no prerequisites, and no alternatives named, which is the minimum bar for a 3.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is partially covered. The description adds nothing beyond that: it does not disclose overwrite behavior, auth requirements, size limits, or what the 'public' flag implies at runtime.

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

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

The single sentence is front-loaded and waste-free, which is good, but it is so terse that it functions more as under-specification than true 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?

For a low-complexity two-parameter upload tool with full schema coverage and annotations covering safety, the description is minimally adequate. It omits any note on overwrite semantics, return value, or the public-accessibility side effect, which would be useful even without an output schema.

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

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

Schema coverage is 100% with only two documented parameters, so the schema carries full parameter meaning. The description adds nothing about the 'path' format or the effect of setting 'public', so the baseline 3 applies.

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

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

The description states a clear verb+resource ('Upload a file'), so an agent understands the action. However, it essentially restates the tool name/title and offers no differentiation from siblings like files_get, files_list, or files_delete.

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 upload versus other files_* tools, nor any prerequisite or context. The operation is relatively unambiguous, but the description provides zero when-to-use direction or alternatives.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the agent knows this is a non-destructive creation call. The description adds genuinely useful behavior — that omission of api_key triggers a hidden-input prompt — but says nothing about the resulting connection's lifecycle, whether it is validated (integrations_test exists for that), or tenant-vs-user visibility beyond what the schema states.

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

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

A single front-loaded sentence with zero filler; the credential mechanism leads and the fallback behavior is parenthetically subordinate. Nothing is wasted and nothing important is buried.

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

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

For a 4-parameter write tool with no output schema, the annotations plus schema carry most of the burden, and the description covers the interactive prompt edge case. It is still thin on post-call expectations — whether the connection is immediately usable or needs integrations_test/enable — which an agent staging a multi-step integration setup would want.

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

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

Schema description coverage is 100%, so all four parameters (provider, api_key, name, user_connection) are already fully documented in the schema. The description restates the API-key parameter and its prompt fallback but adds no syntax, format, or default detail beyond what the schema provides. 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 (connect) and resource (provider) plus the credential mechanism (API key), which an agent can act on immediately. It does not, however, name the sibling it differs from — integrations_oauth_connect and integrations_oauth_callback_url sit right next to it in the list, and the phrase 'with an API key' only implicitly separates the two flows.

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 hints at the interaction model when no key is supplied, which is useful context, but there is no explicit when/when-not guidance and no routing to the OAuth-based connect tools. Usage is only inferable from the word 'API key'.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: no note on scoping (own account vs. workspace), result volume, or pagination for a list 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 short sentence, front-loaded with the verb. It is efficient, though it is terse to the point of omitting information an agent would want.

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 parameterless-required list tool with annotations covering safety and a fully documented schema, the description is minimally adequate. It still leaves return shape and filter behavior unaddressed, which matters since there is no output schema.

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

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

Schema description coverage is 100% and the single parameter's meaning ("Filter to a specific provider") is already documented in the schema. The description adds no syntax, format, or behavioral detail about the filter, 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 clear verb and resource ("List your integration connections"), so the agent knows this is a read of connection records. However, it does not distinguish itself from the many integration siblings (integrations_list, integrations_get, integrations_connect), nor explain what a "connection" is versus an integration.

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 conditions for choosing this over integrations_get or integrations_list, and no mention of the provider filter's role in selecting this tool. Usage must be entirely inferred from the name.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered by structured data. The description adds nothing on top of that: it does not say whether disabling is reversible, whether in-flight workflows or credentials are affected, or what permissions are required. With the lower bar set by annotations, a description that contributes zero extra behavioral context earns a low score.

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 words are perfectly front-loaded and free of filler, but for a state-mutating tool this brevity crosses from concise into under-specified. The structure is clean; the size is arguably too small to carry the tool's weight.

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

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

This is a mutation tool with no output schema and no annotation coverage of effects, so the description carries the burden of explaining consequences. It omits what disabling actually does, whether it can be undone, and how it differs from disconnect, leaving the agent with an incomplete picture for a non-read 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?

There is a single parameter, connection_id, and schema description coverage is 100%, so the schema fully documents the input. The description adds no format, sourcing, or lookup guidance beyond that, which matches the baseline 3 when the schema does the heavy lifting.

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

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

The description names a specific verb ('disable') and resource ('a connection'), so the action is unambiguous at a glance. It does not, however, differentiate itself from close siblings such as integrations_enable, integrations_disconnect, or integrations_connect, and it uses 'connection' where the tool name uses 'integrations'.

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 disable versus when to use integrations_disconnect or integrations_enable, both of which sit in the same sibling set. The agent is left to infer the distinction with no exclusions or prerequisites stated.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive profile is covered. The description adds nothing beyond that structured data: no statement of reversibility, no indication of what is torn down (credentials, tokens, history), and no auth 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?

It is short and front-loaded with the action, which is good. But at three words it reads as under-specification rather than earned conciseness; there was room for a clause identifying the target and any caveats without bloat.

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-undo tool with no output schema, the description leaves out anything an agent needs beyond the bare action: irreversibility, side effects, prerequisites, or error conditions. Annotations carry the safety hint, but the description is too thin to be 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?

There is exactly one parameter (connection_id) with 100% schema description coverage, which already documents its meaning. The description adds no additional semantic detail, so the baseline of 3 for high-coverage schemas 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 verb (delete) and resource (connection), so the core action is legible. However, it is only three words, and the operation is named 'disconnect' in both the tool name and title while the description says 'delete', leaving mild ambiguity about whether the connection is permanently removed or merely unlinked. It also does not distinguish itself from siblings like integrations_disable.

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 naming of alternatives. Given a dense sibling set (integrations_connect, integrations_disable, integrations_connections_list), the description should indicate when disconnecting/deleting a connection is the right call versus disabling it. Nothing is offered.

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

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

Annotations already declare this is a non-read-only, non-destructive, closed-world operation, so the safety profile is covered. The description adds nothing on top: it does not say whether enabling is idempotent, what state change occurs, or what happens to a previously disabled connection.

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 two-word phrasing is maximally concise and front-loaded, but at this length it is under-specified rather than efficient — it omits context an agent needs for a mutation call.

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

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

For a state-changing tool with no output schema, the description should at least say what enabling affects and how it relates to disable/connect. None of that is present, leaving the definition inadequate for correct invocation beyond the bare schema.

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

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

With a single parameter at 100% schema description coverage, the schema already documents connection_id, so the baseline is 3. The description contributes no additional meaning, such as where the connection_id comes from (e.g., integrations_connections_list) or its format.

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?

"Enable a connection" gives a clear verb and an object, so the basic action is identifiable. However, it never clarifies that "connection" means an integration connection, nor does it distinguish itself from siblings like integrations_connect, integrations_disconnect, or integrations_disable.

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 is given. The obvious routing question — when to enable versus connect or disconnect a connection — is left entirely to inference, and the natural counterpart tool integrations_disable is never mentioned.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds nothing beyond that: it does not say the call may perform arbitrary provider-side actions, that results depend entirely on the provider/operation keys, or how failures surface.

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

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

The single sentence is front-loaded and waste-free, but its brevity reflects under-specification rather than disciplined conciseness given the tool's open-world, operation-driven nature.

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

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

For an open-world execution tool with no output schema and 4 parameters, the description omits return shape, error behavior, and how to discover valid providers/operations. An agent cannot confidently call this without consulting sibling tools for context.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema, including the note that operation keys come from 'integrations get <provider>'. The description supplies no additional meaning, which is the baseline-3 case when the schema does the heavy lifting.

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

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

The description states a verb ('Run') and an object ('an operation on a connected provider'), so the general purpose is inferable. However, it gives no sibling differentiation against integrations_test, integrations_get, integrations_connect, or integrations_disable, all of which sound equally plausible for a similar request.

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