ToolYour MCP Server

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation profile is conveyed. The description adds worthwhile scope detail — only *pending* requests can be cancelled — but says nothing about reversibility, permissions required, or what happens to the request record afterward. The unexplained 'Private draft:' prefix adds ambiguity rather than clarity.

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 tight sentence with the action front-loaded. The leading 'Private draft:' tag is unexplained noise that consumes the most prominent position but earns little.

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

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

An output schema exists, so return values needn't be described, and annotations cover the destructive profile. Still, for a destructive mutation the description leaves open what state the request ends in, whether cancellation is reversible, and whether an approval is required — gaps an agent would want filled before calling.

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, requestId, with 0% schema description coverage, so the description must compensate. Saying the request must be 'one of this account's pending provider access requests' does constrain the ID's valid domain, but no format, source (where to obtain the ID), or failure behavior is given.

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

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

Specific verb+resource: 'cancel ... pending provider access requests', scoped to 'this account's'. This implicitly separates it from siblings like request_provider_access, list_provider_access_requests, and disconnect_provider_access, though no sibling is named.

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

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

The word 'pending' implies usage is limited to not-yet-approved requests, and 'this account's' implies an ownership precondition. However, no explicit when-to-use, when-not-to-use, or alternative (e.g. disconnect_provider_access for active access) is articulated.

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/non-destructive profile is covered. The description adds the deprecation status and the auto-capture default, but omits what happens to an existing record on refine, and whether repeated calls duplicate or overwrite.

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

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

Two sentences, front-loaded with the deprecation warning so the agent sees the most decision-relevant fact first. Efficient, though the second sentence's 'automatic capture' reference is slightly ambiguous without a referent.

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

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

The tool has ten parameters with only middling schema coverage and is a mutation, yet the description is two lines and never names a successor tool or the record lifecycle implications. The existence of an output schema removes the need to describe returns, but the deprecation guidance is incomplete without a replacement path.

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 70%, so most parameters are already documented, including title, domain, featureId, and supersedesFeatureId. The description contributes only the loose notion of 'existing record' that hints at featureId, and adds no syntax or behavioral detail for the ten fields.

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: manually create or refine a Feature Memory record, and flags it as a deprecated compatibility tool. An agent can separate it from list_feature_memory, compare_feature_memory, and delete_feature, though it never names the replacement tool.

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?

Communicates that automatic capture is disabled by default, which implies manual invocation, and the 'deprecated' label hints at avoidance. But it gives no explicit when-to-use, no when-not-to-use, and no named alternative for agents that should not call 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?

Annotations declare readOnlyHint=false, so the agent knows this is a mutation; the description adds genuinely useful behavior beyond that — only host runners may call it, and submitting checks does not complete the job. It does not explain what is written, whether resubmission is idempotent, or how the runner credentials (submitHmac/runnerNonce/runnerToken) are used.

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

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

It is short and front-loads the host-runner constraint, but the telegraphic fragments ('Completion-loop:', 'No job_complete.') do not read as complete instructions and one clause is effectively unintelligible. Brevity is achieved here through omission rather than compression.

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 7-parameter mutation carrying signing/nonce/token fields, the description leaves the caller with no guidance on obtaining or supplying those credentials, and no explanation of the results payload shape. The output schema covers return values, but the input side is a substantial gap the description does not close.

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

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

Schema description coverage is 0% across 7 parameters, including security-sensitive ones (submitHmac, runnerNonce, runnerToken) and structural ones (results, gitSha, treeHash) that are entirely undocumented. The only semantic hint is 'Do not invent results,' which tells the agent results must come from real execution but says nothing about field meaning, formats, or which of the two required params pair with which.

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 says 'Completion-loop: host runner only' but never states the actual operation — that it submits check results for a job. Only the schema (jobId + results array) reveals what the tool does, so an agent must open the schema to learn its purpose. The 'verify_task' exclusion does help separate it from one sibling.

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

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

Explicit caller restriction ('host runner only'), two named invocation paths ('toolyour-check-run or control-plane-host.mjs'), and a clear exclusion ('Do not use for skill-loop verify_task jobs'). The 'No job_complete' clause is cryptic rather than clarifying, but the when/when-not framing is otherwise strong.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds two things beyond that: the tool is free and the result includes a composite score plus matrix deltas. It does not explain failure modes or behavior when the two features are incomparable.

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

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

One sentence, front-loaded with the pricing note and the essential purpose, with zero filler. Nothing could be removed without losing information.

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

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

An output schema exists, so return values need no explanation, but with 0% parameter description coverage the definition should say more about the two required IDs. Adequate for a simple two-arg comparison, but with clear gaps given the complexity budget available.

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

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

Schema description coverage is 0%, so the description must carry the load. It clarifies that the two parameters are IDs of previously captured features, which helps, but says nothing about ID format or whether the features must belong to the same workspace/category.

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 (compare) and resource (two captured features) with the output shape noted (composite score + matrix deltas). It is distinguishable from sibling list_feature_memory, though the description never names that sibling explicitly.

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

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

The phrase 'your captured features' implies a prerequisite (features must be captured first via capture_feature) but does not say so outright or point to alternatives. Usage is inferable but not stated, which is the definition of 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 destructiveHint=true, so the agent knows it is a deletion. The description earns credit beyond that by disclosing the blast radius (community copy is also removed when published) and the "Free:" cost signal, though irreversibility and any permission requirements go unstated.

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, scoping detail front-loaded, no filler.

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

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

With rich annotations, an output schema, and a single fully documented parameter, the description covers enough to make the call decision correctly. Only the non-reversibility/permission angle is absent.

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 already explains the fm_… id format and points to list_feature_memory as the source. The description adds nothing about the parameter, 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 (delete) and resource (a captured feature) with explicit scope: private library, plus community if published. That scope note is what separates it from siblings like unpublish_feature_pattern, though the sibling isn't named directly.

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

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

"Use to remove mistaken captures or probe data" gives a use case, which is more than nothing, but there is no when-not guidance and no named alternative for removing a published pattern without deleting the capture.

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

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

Annotations already flag destructiveHint=true, and the description goes further by specifying 'immediately' (no grace period), what is destroyed ('active grants and pilot sessions'), and what is untouched ('the provider or other consumers'). That is real added value beyond the annotations, though the unexplained 'Private draft' marker muddies whether behavior is final and whether the action is reversible.

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

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

Two tight sentences with the destructive action front-loaded, but the leading 'Private draft:' fragment is unexplained noise that competes with the actual action verb for the reader's attention.

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

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

An output schema exists so return values need no explanation, and the annotations carry the safety profile. Still missing for a destructive one-parameter tool: what projectId identifies, whether the revocation is idempotent or reversible, and what happens to in-flight invocations.

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 projectId has 0% schema description coverage, so the description must carry its meaning — but it never mentions projectId, instead speaking of 'this account' and 'one provider API.' An agent must guess how projectId maps onto the described scope, which is a genuine gap in a destructive tool.

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: 'immediately revoke this account's active grants and pilot sessions for one provider API.' It also bounds the blast radius ('does not affect the provider or other consumers'), which implicitly separates it from provider-wide operations, though it never names the nearby siblings request_provider_access or cancel_provider_access_request.

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 guidance and no explicit routing to alternatives such as cancel_provider_access_request, which an agent could easily confuse with this tool. The only hint is the scope statement about other consumers, which describes effect rather than usage conditions. The 'Private draft:' prefix also raises an unanswered question about whether the tool is safe to invoke at all.

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 readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful scope context ('API-backed tools only') and routing behavior, though it does not describe result format or search behavior in more 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?

Two tightly written sentences, with the core scope and routing preference front-loaded. Every sentence carries actionable information.

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

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

The description sufficiently covers routing, scope, and safety context; annotations already cover read-only behavior, and an output schema exists for return values. Remaining parameter details are largely handled by the schema, so an agent has what it needs to select and invoke the tool correctly.

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

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

Schema description coverage is 67%: query and category are well documented in the schema, while limit relies on min/max constraints without a description. The tool description adds no parameter-level guidance beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description names a specific verb and resource ('Advanced catalog search') and adds a clear scope constraint ('API-backed tools only'). It distinguishes the tool from high-level siblings by positioning it as the route for finding a specific operationId, though it does not explicitly contrast with list_categories or search_provider_operations.

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

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

It gives explicit routing guidance: prefer plan_task → run_playbook / solve_task for ship, SEO, and security jobs, and use this only when a specific operationId is needed. This states both when to use the tool and when to prefer 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?

Well past what the annotations convey: it discloses the allowed operation set (approved GET/HEAD only), a contract-revision revalidation step, credential handling (provider-owned, never exposed), and the return shape (body-free receipt). That the underlying calls are GET/HEAD while readOnlyHint=false is not a contradiction — execution is a side-effecting act on a remote system — and the beta flag plus server-gated authorization are exactly the kind of context annotations cannot express.

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

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

Two sentences, no padding, with the beta status and the ownership scope front-loaded before the behavioral guarantees. Dense but every clause carries distinct information an agent needs before calling.

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 high-risk execution tool with one parameter and an output schema, the description covers authorization gates, operation allowlist, validation, credential safety and the receipt being body-free — the agent knows both its obligations and what it will get back. Return-value details are rightly left to the 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?

The single invocationId parameter has 0% schema description coverage, so the description must carry it. 'One ready invocation owned by this account or prepared through a grant' does constrain what the ID must reference, but says nothing about where the agent obtains it or what happens when the ID is stale or not-ready.

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

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

Names a specific verb (execute) and a specific resource (one ready provider invocation), with the ownership/grant scoping that separates it from prepare_provider_invocation and get_provider_invocation. Siblings are never named outright, so an agent must infer the prepare-then-execute pairing rather than being told.

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 preconditions are unusually explicit for a mutation tool: the invocation must be 'ready', and grant-based execution requires independent server gates plus an active consumer execution pilot session. What's missing is the routing half — it never says 'call prepare_provider_invocation first' or points to get_provider_invocation for inspection, leaving the sequencing to inference.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world). The description adds genuinely non-obvious behavior: the store is in-process with a TTL and returns 404 once expired, plus that the call is free. That expiry/404 detail is exactly the kind of operational fact an agent needs and cannot infer from structured 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?

Three short clauses, front-loaded with the action and resource, then cost, then failure mode. No sentence is filler.

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

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

With only one required parameter, a full output schema, and annotations carrying the safety profile, the description covers everything needed to invoke correctly, including the expiry failure mode. Minor gap: it doesn't indicate payload size limits or what a truncated payload's shape looks like, though the output schema likely handles that.

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 already documents dataRefId as a UUID from the summarized response's dataRefId field. The description's mention of 'from a summarized or dataRef response' restates that origin rather than adding new syntax or constraints, 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 (Fetch) and a precise resource (full truncated tool/workflow payload by dataRefId), plus the triggering context (a summarized or dataRef response). An agent can immediately tell this apart from siblings like get_tool_schema or get_run, which serve different purposes.

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?

Clearly names the condition that selects this tool: when a prior response was summarized and exposed a dataRefId. It does not name an explicit alternative or exclusion, but the trigger condition is unambiguous.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context: the resource is 'owned' and 'private,' and the response will never contain encrypted input or provider credentials — useful security disclosure beyond the annotations.

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

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

Two tight sentences with the resource and scope stated first and the security guarantee second. The 'Private draft:' label adds a little noise but costs little.

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

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

An output schema exists, so return-value explanation is not required, and annotations cover the safety profile. However, for a tool whose only parameter is undescribed and whose sibling set is crowded with similar invocation/operation tools, the description leaves the agent without enough to obtain a valid invocationId or rule out adjacent 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 0% and the single required parameter invocationId is never mentioned in the description. The word 'owned' hints at an access constraint, but there is no guidance on the identifier's format, where to obtain it, or what happens on a non-owned ID — the gap the description should have filled.

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 and resource: 'inspect an owned invocation intent and its approval state.' This clearly distinguishes retrieval of an intent's approval state from executing it (execute_provider_invocation) or reading provider operations (get_provider_operation). The 'Private draft:' prefix is ambiguous but doesn't obscure the core 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?

No statement of when to call this versus siblings like get_provider_operation, list_provider_access_requests, or prepare_provider_invocation. The approval-state mention weakly implies 'check before executing,' but no preconditions, alternatives, or exclusions are given.

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

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

Annotations already establish readOnly/non-destructive/closed-world, and the description adds genuinely new behavioral facts: it is metadata only, no invocation occurs, and the response reports whether encrypted invocation preparation, read-only execution, and a consumer pilot session are required. That is useful pre-flight information beyond the structured 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?

The body is dense and front-loads the key capability statement, but the leading 'Private draft:' label is unexplained and could be misread as referring to a draft contract or a draft-stage tool. Otherwise it is appropriately sized for the amount of behavioral detail conveyed.

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

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

An output schema exists, so the return-value hints are a bonus rather than a requirement. However, for a two-required-parameter lookup with zero schema coverage, leaving both parameters uncharacterized is a meaningful completeness 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 0% for two required parameters (projectId, operationId), so the description must carry the burden — but it never mentions either parameter. It doesn't clarify that operationId must refer to an already-approved contract or how projectId scopes the lookup.

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 core sentence names a specific verb ('inspect') and a scoped resource ('one selected and approved provider operation contract'), which distinguishes it from the plural list/search siblings and from get_provider_invocation. The 'Private draft:' prefix is unexplained noise that slightly muddies an otherwise precise statement.

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

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

It states the preconditions for a successful call — the operation must be selected and approved, and the account must own it or hold an active grant — which is real routing context. It does not explicitly contrast with search_provider_operations or get_provider_invocation, so the when/when-not framing is implicit rather than stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, so the safety profile is covered. The description adds real value beyond them: cost is zero ('Free'), status=completed does not mean success so resultStatus must be read, and REDIS_URL governs cross-replica visibility with optional webhooks. It stops short of stating idempotency or polling cadence, so not a 5.

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

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

Extremely front-loaded: the verb-resource-purpose lands in the first clause, then cost, then the critical status caveat. The telegraphic style ('Free.', 'webhook optional.') packs density but borders on cryptic for a reader unfamiliar with the deployment.

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

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

An output schema exists, so return-shape explanation is rightly omitted. The description still covers the two things the schema cannot: that completed ≠ success, and that resultStatus enumerates outcomes (suggest|need_input|verified|error|…). For a one-parameter read tool this is close to complete; the trailing ellipsis leaves the status set slightly open.

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 already documents runId as the UUID returned when async:true, so baseline would be 3. The description adds provenance by naming the four producer tools that mint a runId, which helps an agent validate it has the right kind of identifier.

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 (poll) and the exact resource (async run identified by runId), and enumerates the four sibling tools that produce such runs (solve_task, run_playbook, run_workflow, verify_task). An agent can immediately distinguish this from job_status or check_submit 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?

The condition for use is clear: poll when a task was started with async:true, and it names which producer tools those are. It also flags 'webhook optional' as the alternative delivery path, though it does not explicitly say when to prefer a webhook over polling or how often to poll.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds valuable sequencing context (this precedes invoke_tool) and audience framing ("Advanced"), but says nothing about output shape or whether the schema is complete/normalized — minor given an output schema exists.

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

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

Two sentences, front-loaded with the usage tier and the core action, followed by the exclusion rule. No filler and nothing 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?

A one-parameter read tool with annotations and an output schema needs little more than sequencing and routing guidance, which this provides. The only real gap is not telling the agent how to discover a valid operationId, which would matter for first-time callers.

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 one required parameter with 0% schema description coverage, so the description must compensate. "for one operationId" implies the parameter identifies a single operation, but it never says where operationIds come from (e.g., search_provider_operations) or what format they take, leaving the agent to infer how to obtain a valid value.

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: returns the JSON schema for a single operationId, and positions it relative to invoke_tool. It is immediately distinguishable from siblings like invoke_tool (which executes) and run_playbook/solve_task (which handle higher-level jobs).

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

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

Explicit when-to-use (before invoke_tool, for advanced use) and explicit when-not (skip for ship/SEO/security jobs), naming the two alternatives to use instead. This is the full when/when-not/alternative triad.

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 readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description goes beyond them by enumerating the domain-level side effects that are explicitly NOT performed: access creation, API invocation, provider execution, billing enablement, and publisher network requests. That is useful, non-redundant reassurance for an agent worried about triggering real provider actions, though it does not describe the response shape.

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

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

Two tight sentences with the resource identified first and the safety boundary second. The 'Private draft:' prefix is mildly distracting metadata rather than tool guidance, but the rest is front-loaded and waste-free.

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

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

An output schema exists, so return-value detail is unnecessary, and the no-side-effect profile is well covered. The remaining gap is routing: with many reference/discovery siblings, the description never tells an agent why to pick this one, leaving selection ambiguous.

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 is 4. Nothing in the description is needed to explain inputs, and it correctly presents the tool as a parameterless reference lookup.

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 concrete verb and resource: it returns 'ToolYour's canonical read-only API and MCP reference.' That is more specific than a restatement of the name. It does not, however, contrast itself with close siblings like get_tool_schema or discover_tools, so an agent must infer the difference.

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

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

There is no statement of when to call this instead of get_tool_schema, discover_tools, or list_categories, all of which plausibly return reference-like metadata. The 'Private draft' framing and mention of 'usage boundary' hint at scope but give no selection criteria.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds that calls are 'Advanced' and API-backed (consistent with openWorldHint) plus loop-control guidance, but says nothing about auth requirements, side effects on external systems, or failure behavior. Adequate but not rich.

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

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

Three short sentences, front-loaded with the action and immediately followed by routing and sequencing rules. Dense but every sentence carries information; only 'Advanced:' is loose framing rather than content.

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

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

An output schema exists, so return values need not be explained. However, for a generic meta-invocation tool the biggest question — how to obtain a valid operationId and what to put in `input` — is unanswered, and the description does not point at the sibling discovery tools that resolve it. Adequate for routing, incomplete for correct invocation.

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

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

Schema description coverage is 0% and there are three parameters, including an untyped `input` object and an unexplained `requestId`. The description mentions operationId only as the driver and gives no hint that it must be obtained from search_provider_operations or get_provider_operation, nor what `input` should contain. The description largely fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('run one API-backed tool by operationId') and explicitly positions itself against siblings run_playbook and solve_task. It could go one step further by naming where operationIds come from, but the core action is unambiguous.

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

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

It names the preferred alternatives ('Prefer run_playbook or solve_task for jobs') and gives an explicit post-condition workflow ('After a jobReport, apply loop.remainingFixes then verify_task — do not re-invoke the same tool'). The condition that selects this tool over alternatives is stated rather than inferred.

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

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

Annotations already flag destructiveHint=true and openWorldHint=false; the description goes further by disclosing the human-in-the-loop requirement, the required CONTROL_PLANE_APPROVE_TOKEN credential, and the breakGlass escalation path for critical actions. It stops short of saying whether an approval is revocable or what happens after approval is recorded.

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 short fragments, zero filler, with the scope constraint and actor restriction front-loaded. The telegraphic phrasing is dense enough that a couple of clauses require a second read, keeping it off a 5.

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

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

An output schema exists so return values need no explanation, and the authorization model is well covered. However, with 5 parameters at 0% schema coverage, the complete absence of jobId and expiresAt semantics leaves a real gap for a destructive approval gate.

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

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

Schema description coverage is 0%, so the description must carry the load. It explains actionId (one declared action), approveToken (CONTROL_PLANE_APPROVE_TOKEN), and breakGlass (needed for CRITICAL), but leaves jobId and expiresAt — the latter materially affecting approval lifetime — completely undefined.

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 (approve), the exact resource granularity (one declared actionId, scoped), and the actor constraint (human-only). An agent can distinguish this from job_declare_action and job_cancel 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?

"No approve-all" and "CRITICAL needs breakGlass" give concrete when-to-use conditions, and the token requirement is a stated prerequisite. It does not name sibling alternatives explicitly, so it stops just short of a 5.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is known; the description adds a real precondition beyond that ('open frozen job only'), telling the agent the tool will fail on closed jobs. It does not state whether cancellation is reversible or what a successful cancel leaves behind.

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

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

Two short sentences, zero filler, with the action and its scope stated first and the exclusion immediately after. Nothing is over-explained.

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

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

An output schema exists, so return values need not be described, and the annotations carry the safety profile. What remains thin is the failure mode — behavior on a non-open or already-cancelled job — and any description of the sole parameter.

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

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

One required parameter with 0% schema description coverage, so the description was the only place to explain it — yet jobId is never mentioned. The agent gets no hint about format, where to obtain the job ID, or whether it accepts an external identifier.

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 (cancel) and resource (an open frozen job), plus an explicit boundary against skill-loop runs. The 'Completion-loop:' prefix and the term 'frozen' are unexplained jargon, but the core action is unambiguous.

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

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

Gives a clear exclusion — do not use for skill-loop runs, use the run lifecycle instead — which routes the agent away from a wrong path. It does not cover when to prefer this over job_approve/job_status or what to do if the job is not open, but the primary disambiguation is present.

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 not read-only, not open-world, and not destructive. The description adds useful context that undeclared shell commands are invisible and that this is not a blanket approval, but it does not explain what declaration actually does, whether it grants execution rights, or how it interacts with approval workflows.

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

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

The description is three short sentences, front-loads the core action, and contains no filler. Every sentence contributes either purpose, operational context, or a usage warning.

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

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

Although an output schema exists and annotations cover basic safety traits, the description is too thin for a seven-parameter declaration tool with no schema parameter descriptions. An agent still lacks guidance on required fields like actionClass, resourceGlob, and iteration bounds.

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

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

Schema description coverage is 0% for seven parameters, so the description carries the full burden of explaining parameter meaning. It only echoes the HIGH/CRITICAL risk enum and gives vague hints like 'for this job' and 'host action,' leaving required fields such as actionClass, resourceGlob, and jobId essentially undocumented.

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

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

The description states a specific verb and resource: declaring a HIGH or CRITICAL host action for a job. It also distinguishes the tool from a blanket approval mechanism with 'Not an approve-all,' though it does not explicitly name the sibling approval tool.

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

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

Usage is implied by the warning that ToolYour cannot see undeclared shell commands, suggesting this tool should be used to make such actions visible. The 'Not an approve-all' phrase adds a partial exclusion, but the description does not explicitly say when to use this versus job_approve or related 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?

The annotations already establish that this is a non-read-only, non-destructive, closed-world operation, and 'start' is consistent with readOnlyHint=false. The description adds useful workflow context about frozen tasks and jobId handling, but it does not describe permissions, idempotency, side effects, or when startToken is needed.

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 front-loaded with the core action and uses only three short sentences. Every sentence adds routing or scoping value, with no repetition or filler.

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

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

For a two-parameter start tool with annotations and an output schema, the description covers purpose, allowed task IDs, and key alternatives well. The main residual gap is the unexplained optional startToken parameter.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It clarifies the taskId values by saying they are frozen tasks and listing the allowed options, but it does not explain the optional startToken parameter at all.

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

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

The description names a specific verb and resource: start a frozen task. It lists the exact task identifiers and distinguishes the tool from plan_task and job_status, so an agent can identify its purpose 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?

It gives explicit exclusions — not for SEO, URLs, or ship-gate — and names the correct alternative, plan_task. It also states that agents with an existing jobId must use job_status, which directly resolves a likely routing ambiguity.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the precondition that the jobId must already exist and names the returned facets, but since an output schema exists those field names are partly redundant. No mention of polling cadence or what 'frozen checks' implies behaviorally.

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

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

Two sentences, zero filler: the operation and its return facets come first, the routing exclusion second. Every clause carries information an agent needs.

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

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

For a one-parameter read-only status tool with an output schema and clear annotations, this covers what to pass and when not to use it. The remaining gap is that it does not tie itself to the job lifecycle siblings (job_start, job_approve, job_cancel), so an agent must guess the sequencing.

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

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

Schema coverage is 0% for the single jobId parameter, which the schema types only as a bare string. The description compensates slightly by qualifying it as an 'existing jobId', implying it must originate from a job creation/approval sibling, but it never says which tool produces that id.

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-less but concrete operation: retrieve completion-loop status for an existing jobId, and names the payload fields (state, frozen checks, next_action). This distinguishes it from plan_task, though the term 'completion-loop' is internal jargon an agent may not decode without prior 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?

Explicitly excludes catalog/SEO goals and routes that case to plan_task, which is a real alternative among siblings. It never states the positive trigger — e.g. that it is called after job_start/job_declare_action to poll progress — so the when-to-use half is left to inference.

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

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

Annotations already cover the safety profile (readOnlyHint true, destructiveHint false, openWorldHint false), and the description adds a genuinely new, decision-relevant trait: the call is free / not billed. It stops short of describing the shape of the returned categories (e.g. whether the list equals valid category values), but the output schema carries that.

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: purpose first, then the usage rule and example. Nothing redundant for a zero-arg tool.

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

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

An output schema exists and annotations are rich, so the description only needed to establish purpose, ordering relative to discover_tools, and cost — all of which it does.

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-parameter tool, so the baseline applies; the description correctly adds no parameter talk yet usefully demonstrates how its output feeds a parameter on a different tool.

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

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

Specific verb plus resource ("List tool category families") with concrete enumerated examples, and it names the sibling it feeds into (discover_tools), so an agent can tell exactly what this returns versus the discovery tool.

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 sequencing ("Use before discover_tools to narrow search") plus a worked call example showing the category argument, which removes any ambiguity about when this tool is the right choice.

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 genuinely new context: it is free (no quota cost), the data is opt-in and anonymized, and private project labels are excluded. Return format and pagination are left unaddressed.

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

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

Three short front-loaded clauses with no filler; the cost and privacy qualifiers arrive before the filtering detail. Slightly clipped to the point of under-specification rather than being verbose.

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

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

An output schema exists, so return values need no explanation, and the read-only annotations cover the safety profile. For a simple two-parameter read tool the description supplies the essential context (free, anonymized, domain-filtered, no private labels); only the 'limit' parameter is a residual gap.

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

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

Schema description coverage is 0%, so the description must carry the load. It explains that 'domain' is a filter, but 'limit' is never mentioned and no format, enum, or default is given for domain either, leaving half the parameter surface undocumented.

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 ('browse opt-in community feature patterns') plus a scope exclusion ('does not include private project labels'), which distinguishes it from private-memory siblings like list_feature_memory. It never names those siblings, so differentiation requires inference.

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

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

The 'does not include private project labels' clause implicitly tells the agent when this tool is wrong (private data), but no alternative such as list_feature_memory or publish_feature_pattern is named, and there is no guidance on when the community corpus is the right source.

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 destructiveHint=false, so safety is covered. The description adds meaningful context by calling it a deprecated compatibility tool and noting that records are private. It still does not explain pagination behavior, permission requirements, or what makes the records private.

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 efficient sentence. The deprecation warning is front-loaded, and no words are wasted.

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

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

The tool is relatively simple and has an output schema, so return values need not be explained. However, both optional parameters are undocumented in the schema and the description, so an agent lacks guidance on filtering or limiting results. The description covers purpose and deprecation but not enough operational detail.

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 are two parameters, limit and domain, with 0% schema description coverage. The description does not mention either parameter or explain their meaning. With low schema coverage, the description should compensate, but it does not.

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

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

The description gives a specific verb and resource: list existing private Feature Memory records. It also flags the tool as a deprecated compatibility tool, which is useful. However, it does not explicitly distinguish this tool from nearby siblings such as compare_feature_memory or delete_feature.

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 intended use cases: export, review, or deletion. This implies when the tool is appropriate, but it does not name alternatives or say when not to use it. The deprecation note is a useful warning but is not usage routing.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description still adds real value beyond them: it scopes the result to 'this account', clarifies that access state is volatile (revoked/expired/temporarily unavailable), and states the response is metadata only — a meaningful disclosure about what is not returned.

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 core action, with no filler. The only inefficiency is the unexplained 'Private draft:' tag, which occupies prime position without telling an agent 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?

With zero parameters and an output schema present, the description only needs to convey scope and result nature — which it does via 'this account', 'current access state', and 'metadata only'. The one gap is the unexplained 'Private draft' qualifier, which may signal a stability or visibility caveat the description does not resolve.

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, which is the baseline-4 case. Nothing in the description misrepresents the input surface, and the account scoping is stated in prose even though it is implicit in the empty 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?

Clear specific verb and resource: 'list this account's provider access requests and current access state.' An agent can distinguish it from request/cancel/disconnect siblings by the listing verb, though the description never names those siblings explicitly. The 'Private draft' prefix adds ambiguity rather than precision.

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

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

Usage is only implied — an agent can infer this is the read/status counterpart to request_provider_access, cancel_provider_access_request, and disconnect_provider_access, but no when-to-use or when-not-to-use condition is stated. The note that approved requests can be revoked, expire, or become unavailable hints at the polling/status use case without committing to 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?

Annotations already declare readOnly=true, destructive=false and openWorld=false; the description goes beyond them by clarifying that results are 'metadata only' and that it 'does not invoke provider APIs' — a meaningful distinction in a family full of execute/invoke tools. It does not disclose pagination limits at the end of a cursor chain or any output shape, but the output schema covers the latter.

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

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

Three short sentences, each carrying information: scope, pagination discipline, and the metadata-only guarantee. The 'Private draft:' prefix is noise that does not help an agent decide anything.

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

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

With an output schema present, return values need not be described. The description covers scope, access modes, pagination and the non-invocation guarantee — enough to call it correctly. The remaining gap is the undocumented 'limit' parameter and default access 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 0%, so the description must carry the burden. It explains that 'access' selects one of three scopes (owned / granted / free) and maps to the enum, which is real added value. However, the cursor parameter is actually named 'cursor' in the schema while the description calls it 'nextCursor', and the 'limit' parameter is never mentioned at all, so compensation is only partial.

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

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

States a specific verb and resource ('list API projects this account owns, has an active discovery grant to use, or may discover through a free metadata policy'), which tells an agent exactly what set is returned. It does not explicitly differentiate from the nearest sibling, list_provider_access_requests, so it stops short of a 5.

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

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

'Use one access mode with nextCursor for stable pagination' gives guidance on how to combine parameters, which implies the iteration pattern. But there is no statement of when to choose this tool over list_provider_access_requests or discover_tools, and no prerequisites or exclusions.

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

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

Annotations already cover read-only safety; the description adds real workflow context — the list→run_playbook→verify_task sequence and the prohibition on invoke_tool. It does not cover filtering behavior or result shape, but it exceeds baseline for an annotated 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?

Terse and front-loaded — purpose first, then routing constraints. Dense but each clause carries routing information; the 'Primary jobs' list is cryptic without further 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?

Output schema exists so return values needn't be explained, and annotations cover safety, but the undocumented `category` parameter leaves a real gap for a listing tool.

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

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

The single `category` parameter has zero schema description coverage, and the description never mentions it or explains what values it accepts. With 0% coverage the description should compensate but adds nothing here.

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 ('List skill playbooks') and names the sibling it routes to (run_playbook) plus the follow-up (verify_task). It distinguishes itself from run_playbook and invoke_tool, though 'skill playbooks' is somewhat jargon-heavy and load_skill isn't addressed.

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 prefer run_playbook(skillId) immediately and to call verify_task after a run, and gives a hard exclusion ('do not invoke_tool'). Clear routing, but it never says when to use list_skills itself versus load_skill.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds only that the return is the full markdown playbook, plus an output schema that likely documents the shape. No mention of size, auth, or truncation behavior beyond what annotations and the output schema already give.

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

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

Two short sentences with zero filler; the primary action is stated first and the routing hint second. Every clause carries information.

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

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

Because an output schema exists, the description needn't explain return values, and the read-vs-execute distinction is handled. The real gap is the sole required parameter with no schema documentation and no description of where skillId is obtained, which is exactly what an agent needs before calling.

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 required parameter skillId has 0% schema description coverage, so the description is the only place semantics could be supplied — and it says nothing about it. It never explains that the ID comes from a discovery call such as list_skills or what format it takes, leaving the agent to guess where the value originates.

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

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

Specific verb+resource: 'Load full skill playbook markdown' tells the agent exactly what comes back (markdown playbook text). It also names a sibling, run_playbook, that an agent might otherwise confuse it with. It does not, however, distinguish itself from list_skills, which is the natural discovery counterpart.

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

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

'Prefer run_playbook to execute in one step' gives an explicit alternative and the condition (execution) that selects it, which implicitly frames load_skill as the inspection path. It stops short of explicitly stating when to read versus execute, so the agent must infer the read-only-inspection use case.

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

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

Annotations already establish read-only, non-destructive, closed-world behavior, so the bar is lower. The description still adds real value beyond them: it discloses that the tool returns a ranked recommendation and loop decision, that it is free, and that it performs no execution — an agent knows it is safe to call and produces advice, not side effects.

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

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

Two tight sentences with zero filler. The purpose and the domain scope are front-loaded, and the non-execution caveat follows immediately where it matters.

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

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

An output schema exists, so return values need not be spelled out, and annotations cover safety. However, the undefined 'input' object and the vague qualifier 'supported ... jobs' leave a real hole for a planning tool whose output drives downstream execution.

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

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

Schema coverage is only 50%: 'goal' is documented in the schema, but 'input' is an untyped, undescribed object. The description says nothing about either parameter, so it does not compensate for the gap — an agent has no guidance on what to place in 'input' or how it differs from 'goal'.

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 function (a skill-loop planner for SEO, security, ship-gate, and catalog jobs) and adds a scoping clause — 'it does not execute the work' — that separates it from executor siblings like solve_task or run_workflow. The verb is nominal ('planner') and no sibling is named explicitly, so it falls short of a 5.

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

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

The phrase 'it does not execute the work' implies this is a pre-execution planning step, but there is no explicit when-to-use rule, no named alternative (solve_task, run_workflow, job_start), and no statement of what to do with the returned loop decision. Usage must be inferred.

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

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

Annotations only declare readOnlyHint=false, destructiveHint=false, openWorldHint=false; the description adds substantially more: the result is a private encrypted draft, the operation is idempotent, no provider call occurs, and granted-path preparation is gated by server-side checks plus an active pilot session. It does not explain encryption scope or idempotency-conflict behavior, so not a 5.

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

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

Three tight sentences, front-loaded with the action and artifact, then eligibility, then the negative boundary. Every sentence carries information; density comes from domain jargon rather than filler.

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

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

An output schema exists, so return values need not be described. The description covers eligibility, gating, and the crucial fact that no provider call happens. Remaining gap is the lifecycle linkage — what the returned intent is consumed by (presumably execute_provider_invocation) and how long the draft stays valid.

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 50%: 'input' and 'idempotencyKey' are documented in the schema, while projectId and operationId are bare strings. The description indirectly constrains operationId ('owned approved operation or a granted read-only operation') and implies idempotency via 'idempotent', but adds nothing about projectId or how idempotencyKey interacts with replay. Partial compensation for the coverage gap, so a 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 concrete verb and artifact ('create an encrypted, idempotent invocation intent') scoped to two eligible operation types (owned-approved or granted read-only). The closing clause 'This does not call the provider' cleanly separates it from the sibling execute_provider_invocation. Minor deduction because 'owned approved operation' and 'granted read-only operation' are internal jargon that an agent may not fully resolve.

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?

Preconditions are stated (approved operation, granted read-only, independent server gates, active consumer pilot session), which is real usage context. However, it never explicitly says to use execute_provider_invocation to actually perform the call, nor when to prefer this over get_provider_invocation or request_provider_access. The alternative is only implied via negation.

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 only declare readOnlyHint=false, openWorldHint=true, destructiveHint=false — the mechanically checkable facts. The description goes beyond them with substantive context: publication is opt-in, anonymization redacts project/repo, and exactly what third parties can see (requirements + matrix only). It omits reversibility/visibility scope details, keeping it short of a 5.

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

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

A single dense sentence with the value proposition and the consent model front-loaded before the privacy guarantee. Slightly telegraphic phrasing ('Free:', 'requirements + matrix') but no wasted sentence.

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

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

One required parameter, full schema coverage, and an output schema, so return values need no explanation. The description supplies the privacy/visibility framing an agent needs for a write operation with open-world reach; only the reversibility story (via unpublish) is unstated.

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

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

Only one parameter, and the schema already documents it fully (coverage 100%) including the 'fm_… id from capture_feature or list_feature_memory' provenance. The description adds nothing about the parameter beyond that, so the baseline 3 applies when the schema carries the semantics.

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

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

States a specific verb (publish) and resource (a captured feature to the anonymized community library), plus the effect (project/repo redacted, others see requirements + matrix). The verb+resource pair and the 'captured feature' input make it distinguishable from capture_feature and unpublish_feature_pattern, though it never names those siblings directly.

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

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

'Opt-in' and 'Free' together imply the user-consent precondition for calling this, which is real guidance about when it is appropriate. However, there is no explicit statement of when to prefer this over list_community_patterns or how it relates to unpublish_feature_pattern, so routing is left to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description's meaningful addition is the deprecation/lifecycle context, but it says nothing about return shape, scoping behavior, or what happens if no records match — modest added value over the annotations.

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

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

Two compact sentences with zero filler, and the most decision-relevant fact — that it is deprecated — is front-loaded before the functional description.

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

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

An output schema exists, so return values need not be explained, and the deprecation status plus account scoping are both disclosed. The only missing piece is a named successor tool, which would fully complete the guidance for a deprecated compatibility shim.

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 three parameters, including the enum on memoryType and the goal description, so the schema carries parameter semantics fully. The description adds no parameter-level detail such as how the goal string drives memoryType inference, making a baseline 3 appropriate.

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

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

The description states a specific verb and resource — recalling existing Feature Memory records scoped to the owning account — so the agent knows exactly what the tool does. It does not, however, differentiate itself from the nearby list_feature_memory, compare_feature_memory, or capture_feature siblings beyond the deprecation note.

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?

'Deprecated compatibility tool' and 'no longer part of the default planning path' clearly signal when NOT to reach for it, which is a real routing benefit. The one gap is that it never names the tool an agent should use instead, leaving the replacement 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 only say it is a non-read-only, non-destructive, closed-world call. The description adds real behavior beyond that: no grant exists until the provider explicitly approves, and the reason field is stored as metadata so credentials or request/response content must not be included. Only the response shape and what happens after approval are left unstated, which the output schema covers.

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

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

Three short sentences, front-loaded with purpose and followed by the approval condition and the sensitive-data warning. 'Private draft:' is slightly ambiguous phrasing but costs little space.

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

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

With an output schema present, return values need not be described, and the approval gate and data-handling warning are useful. Still, an agent choosing values for capabilities and projectId gets nothing from either schema or description, which is a meaningful gap for a 4-parameter tool.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden. It only implicitly covers operationIds ('selected approved provider operations') and reason ('metadata only'), while projectId and especially the capabilities enum (discovery/invocation/execution) are never explained, leaving the agent to guess what capability level to request.

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 (request access to selected approved provider operations) and notes the draft nature of the request. It is distinguishable from siblings like cancel_provider_access_request and list_provider_access_requests, though it never names the alternative tools for finding operation IDs.

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?

Implicitly says when to use it (to obtain access to approved provider operations), and the approval requirement clarifies the workflow stage. However it gives no explicit when-not guidance or pointer to the sibling used to look up approved operations (e.g. search_provider_operations / list_provider_projects).

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 known. The description adds meaningful lifecycle behavior beyond that: results serve as a baseline, profiles persist for regression, and verification flows through verify_task. It still doesn't say what environment changes the run causes or what permissions are needed for an open-world execution, so it falls short of a 5.

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

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

Three short sentences with the capability, the prerequisite read, and the downstream chaining, in priority order. No filler; the alternative-tool routing is packed into a single clause.

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

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

An output schema exists, so return-value explanation is unnecessary, and the description covers selection, prerequisites, and follow-up. The remaining gap is behavioral detail for an open-world, non-read-only execution (what the playbook touches, resource cost), which keeps it at 4.

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 60%, so some compensation is expected; the description explains that profileId (or the returned result) acts as a baseline for verify_task, giving semantic meaning the schema's 'reuse a verification profile' line only hints at. async and responseMode remain undocumented in both places, keeping it below 5.

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

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

Opens with a specific verb + resource ('Run a skill playbook') and gives concrete examples of playbook families (ship-gate, production-readiness-gate, SEO audit). It also explicitly positions itself against siblings load_skill and invoke_tool, so an agent can select it without inspecting 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?

Gives an explicit preference rule ('Prefer over load_skill or invoke_tool') and a concrete follow-up workflow ('After host fixes, verify_task with this result as baseline (or profileId)'). It even orders prerequisite reading (verification.evidence + loop.line first), which is actionable selection guidance rather than vague 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 the mutation profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the description's job is to add context beyond that. It does contribute useful flow context — the return of loop.remainingFixes and the follow-up call to verify_task — but is silent on auth, side effects of the multi-step job, or what 'loop' means.

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

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

Three compact fragments, verb and identifier front-loaded, with the routing hint immediately after. Terse to the edge of being cryptic, but nothing is wasted.

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

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

The output schema exists, so return values needn't be spelled out, yet three of four parameters remain unexplained. The description covers the calling flow and follow-up verification but leaves an agent unable to configure the request fully.

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

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

Schema description coverage is 0%, so the description must carry the burden, yet it only names workflowId. The async, input, and responseMode parameters (including an enum) are undocumented in both schema and description, so an agent has no basis for setting them.

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

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

States a specific verb+resource ('Run a named multi-step job by workflowId') and explicitly distinguishes itself from close siblings run_playbook and solve_task. The one gap is that 'workflow' vs 'playbook'/'task' semantics are never defined, leaving the distinction partly inferential.

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?

'Prefer run_playbook (skill) or solve_task (goal)' gives the agent an explicit routing rule that names the alternatives and the condition selecting them. It stops short of stating when run_workflow IS the correct choice (e.g., when you already hold a workflowId).

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

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

Annotations already cover safety (readOnly, non-destructive, closed-world), so the bar is lower, yet the description adds real behavioral context: results are labeled by ownership, delivery channel, availability, and plan scope, and it discloses what is intentionally withheld. It doesn't mention limits on result size beyond cursor behavior, which would round it out.

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, front-loaded with the resource scope, then filters/pagination, then exclusions. The 'Private draft:' prefix and the AI-ish 'ToolYour-owned' phrasing waste a little space and could confuse an agent about whether the tool is usable.

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 9 params, an output schema, and annotations, the description covers what an agent needs to decide suitability and paginate safely. Gaps remain around `projectId` scope, when `requestable` vs `granted` diverge in practice, and empty-result behavior, but nothing critical is missing.

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

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

Schema coverage is 44%, so the description should carry more than it does. It adds meaning for `access` (mode-scoped pagination) and `cursor` (stable, access-scoped) but leaves `projectId`, `limit`, `query`, and `tag` with no added semantics. Its category gloss merely restates the schema description.

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

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

States a specific verb and resource with its scope: searching operation *metadata* across owned, granted, free, and requestable access. It carves out a distinct niche against siblings like get_provider_operation and get_tool_schema by explicitly excluding schemas, credentials, provider responses, and invocation. It stops short of naming a sibling alternative outright, so differentiation is inferable rather than explicit.

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

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

Gives concrete guidance on how to paginate ('use one access mode with nextCursor') and what to filter by (provider, risk, tag, category). The 'does not expose schemas... does not invoke APIs' lines imply an agent should route to get_tool_schema or invoke_tool instead, but no tool is named. Usage is implied rather than prescribed.

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

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

Beyond the annotations, which mark this as a non-read-only open-world write with destructiveHint=false, the description adds meaningful behavioral context: workflow runs attach verification.evidence and profileId, and the loop.line/initiate flag controls whether work continues. That is real post-invocation semantics an agent would not get from the annotations. It loses a point for leaving key terms like 'rank-1' and 'loop.line' undefined.

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

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

Three short sentences, front-loaded with the core action and followed by the output-handling rule. There is no filler, but the dense internal jargon makes it less accessible than it could be.

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

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

An output schema exists, so return values need not be explained. However, the description introduces concepts (loop.line, initiate, rank-1) that are not defined anywhere in the visible schema, and it never clarifies its relationship to plan_task or run_workflow, leaving an agent uncertain about the full workflow contract.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters, including the goal/url guidance and the async behavior. The description adds essentially no parameter-level detail beyond what the schema provides, 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?

The description says it will 'Run a job from a plain-language goal,' which gives a verb and resource. However, 'job' is undefined, and it is never distinguished from siblings like plan_task, run_workflow, or run_playbook, except by saying one behavior is 'same as run_playbook.' Terms such as 'loop.line' and 'rank-1' are left unexplained, so the purpose is inferable but fuzzy.

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 does give procedural guidance for what to do after the call: read loop.line, stop if initiate is false, and otherwise apply rank-1 and then call verify_task. It does not say when to choose solve_task instead of plan_task or run_workflow, so the guidance is implied rather than explicit.

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

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

Annotations already flag destructiveHint=true, but the description adds the crucial qualifier that the private copy survives, so 'destructive' applies only to the community listing — that genuinely refines the safety picture beyond structured fields. It still omits auth/skill requirements and whether the public listing's history or mentions are lost.

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 the key retention guarantee in second position — efficient. The unexplained 'Free:' prefix costs a little clarity without contributing meaning.

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

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

For a one-parameter mutation with an output schema available, this covers the essentials of what the call does and what survives. It leaves open whether the removal is reversible, what permissions are needed, and what the response reports — gaps that matter for an irreversible-looking destructive action.

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 featureId documented as 'fm_… community feature id', so the description adds nothing new about the single parameter beyond confirming the 'community library' context. Baseline 3 is appropriate when the schema fully documents the input.

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 pair: remove a feature from the community library. The clause 'while keeping it in your private memory' distinguishes it from the nearby delete_feature and complements publish_feature_pattern, so an agent can tell what it does. It never names those siblings explicitly, and the leading 'Free:' token is unexplained noise.

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 purpose implies when to use it (you want the item out of the public library but retained locally), and the alternative — full deletion — is hinted at rather than named. There is no explicit 'use X instead when…' routing, no prerequisites, and no statement about whether the action can be undone by republishing.

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, openWorldHint=true, so the agent knows this is a non-read-only, non-destructive, open-world operation. The description adds procedural behavior — reads verification.evidence + loop.line, applies rank-1 loop.nextActions, stops when loop.stop is set — which is genuine beyond-annotation context, though it is stated in undefined internal terminology.

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 short sentences with no filler, but the lead sentence is a precondition rather than a purpose statement, and the rest is dense with unexplained field paths (loop.initiate, loop.line, loop.nextActions) that an agent must already know. Front-loading the what before the when would make it substantially more usable.

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

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

An output schema exists, so return values needn't be explained, but the description leans entirely on undefined jargon — 'loop.initiate', 'loop.line', 'rank-1 loop.nextActions', 'verification.evidence' — without indicating where these come from or what applying an action entails. For a six-parameter, open-world execution tool, an agent cannot reliably determine what this call actually does to its environment.

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

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

Schema coverage is 67% and the schema already documents async, input, baseline, and profileId. The description adds only the conditional relationship between baseline and profileId ('profileId with a prior run_playbook snapshot'), and says nothing about the required 'goal' parameter or responseMode beyond what the enum conveys — baseline 3 is appropriate at this coverage level.

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 implies a verification/loop-closing step and distinguishes itself from solve_task/run_playbook by requiring a prior baseline, but it never plainly states 'verify the goal outcome against a prior result.' The metaphor 'Close the loop' plus jargon like 'rank-1 loop.nextActions' leaves the core purpose to inference from the name and the 'verification.evidence' reference.

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

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

It gives real preconditions: only when the prior result has loop.initiate true, and requires either a baseline jobReport or a profileId with a prior run_playbook snapshot. However there is no explicit statement of when to prefer solve_task vs verify_task, and the gating condition is phrased in internal-field jargon rather than a decision an agent can evaluate without prior context.

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