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

The description adds value beyond annotations by clarifying that token values are never returned and detailing Meta action-block state behavior (block.tracked is false until a block was recorded). It aligns with readOnlyHint and provides useful behavioral context.

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

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

The description is concise (two sentences), front-loaded with the main purpose, and contains no redundant information. Every sentence adds value.

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 no output schema, so the description must clarify return values. It lists categories but does not specify the output structure (e.g., object keys, format). Given moderate complexity, the description is adequate but could be more complete.

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

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

The only parameter (clientId) has full schema coverage (100%) in the input schema, which already describes it as optional and defaulting to active client. The description does not add further parameter semantics, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns connection health per platform (Meta/LinkedIn/YouTube) and lists included fields (configured, authenticated, token expiry, etc.). It distinguishes from sibling tools by focusing on status overview, though it does not explicitly name alternatives.

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

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

The description implies usage by stating what information is returned (connection health, token expiry, etc.) and that it is read-only. However, it does not provide explicit when-to-use vs alternatives like health_recheck or platform_validate, nor any 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 declare readOnlyHint=true; description adds context about event types and response fields, enhancing transparency beyond annotations. No contradictions.

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?

Description is a single dense sentence that front-loads purpose and lists fields. Efficient but could be slightly clearer; still earns a 4.

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

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

No output schema exists, so the field list and ordering ('newest first') are essential and provided. Purpose and read-only nature are clear. Missing details on filtering or pagination are minor given tool simplicity.

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 provides full descriptions for both parameters (limit, clientId) with 100% coverage. Description adds no additional parameter-level information, so baseline score of 3 is appropriate.

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

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

Description clearly identifies the tool as the 'pendpost audit feed' listing specific event types (publish attempt, scheduler start/stop, circuit-breaker) ordered newest first. It distinguishes itself from sibling tools, none of which are audit/log-oriented.

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

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

The description implies usage for retrieving audit events but does not explicitly state when to use this tool versus alternatives, nor does it mention when not to use 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 indicate readOnlyHint=false and destructiveHint=false. The description adds key behavioral context: the approval authority (owner) and the self-approval prohibition. It does not contradict 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?

Three concise sentences with no extraneous information. Each sentence adds critical value.

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

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

For a simple mutation tool with no output schema, the description provides sufficient context: purpose, usage rules, and authorization constraints.

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 60%, and the description adds meaning to the 'actor' parameter by explaining who can approve. For other parameters, the schema descriptions suffice.

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

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

The description clearly states the tool's purpose: 'Approve a post for publishing'. It distinguishes from sibling 'reject_post' by mentioning approval and the rule against self-approval.

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 states when to use: only on the owner's instruction. Also specifies who cannot use it: the creator of the post cannot self-approve.

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 description explicitly states 'Read-only' and details the full return content (ffprobe specs, cover JPEG, plan usage, captions). This adds significant value beyond the readOnlyHint annotation, which only indicates safety.

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 sentence but includes a thorough list of returned data. It is front-loaded with the main action, but slightly verbose. Acceptable conciseness.

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

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

Without an output schema, the description fully explains what the tool returns: specs, spec checks, cover JPEG, plan posts, and captions. This is complete for a read-only list tool with a single optional 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 coverage is 100% with a clear description for the only parameter (clientId). The tool description does not add additional parameter semantics, 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 clearly states the verb 'list' and the resource 'publishable renders', and specifies the detailed information returned. It distinguishes the tool from siblings like delete_asset or rename_asset by focusing on listing read-only data.

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

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

The description provides context for when to use the tool ('canonical source when drafting social copy'), but does not explicitly state when not to use it or name alternatives. However, the sibling list implies other asset tools for mutations.

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 indicate non-read-only and non-destructive, which the description supports by stating it creates files and refuses to overwrite. However, it lacks details on authentication, rate limits, or return behavior, leaving gaps 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?

The description is very concise at two sentences, with the main purpose front-loaded and no extraneous information, making it easy to parse.

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

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

For a simple upload tool with no output schema, the description covers purpose, input constraints, and behavioral rules. It misses potential details like size limits or file path accessibility, but remains fairly complete for its complexity.

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

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

With 80% schema description coverage, the baseline is 3. The description adds marginal value by clarifying mutual exclusivity of filePath and base64 and noting 'repo-local' for filePath, but mostly reiterates schema-provided details.

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

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

The description clearly states the verb 'Ingest' and the resource 'data/media (the asset library)', effectively distinguishing it from sibling tools like assets_list, delete_asset, rename_asset, and validate_media.

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

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

The description provides guidance on input methods (filePath vs base64) and constraints (file extensions, no overwrite), but it does not explicitly contrast with sibling validate_media or specify when to prefer this over 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?

Beyond the readOnlyHint annotation, it explains the tool returns errors and warnings with different severities, adding behavioral context beyond annotations.

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

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

The description is dense but efficient, front-loading the core purpose and listing specifics without redundancy.

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

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

Given no output schema, the description explains the tool's behavior and outputs (errors/warnings) adequately, though could mention return format.

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 description explains the 'text' parameter (not described in schema) and clarifies how the 'platform' parameter tunes caps, adding value beyond the schema descriptions.

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

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

Description clearly states it lints caption/copy text against brand rules, listing specific checks like platform hygiene and AI-tells. This distinguishes it from siblings by its unique function.

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 advises 'Run over every caption before proposing it.' and clarifies that errors block publish while warns are advisory, providing clear context for when to use the tool.

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

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

Annotations indicate the tool is not read-only and not destructive. The description adds value by specifying exactly what files are written and the activation effect. However, it does not mention authorization requirements or idempotency, which would enhance transparency.

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, well-structured sentence that front-loads the main action and includes essential side effects. Every word adds value with no redundancy.

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

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

Despite lacking an output schema, the description adequately conveys the tool's primary effects. It could mention return values or error conditions, but the current completeness is sufficient for a creation tool with clear side effects.

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% (below 80%), so the description should compensate for undocumented parameters. However, the description does not add meaning to any parameter beyond what the schema already provides. For example, 'actor' lacks schema description and is not mentioned in the tool 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?

The description explicitly states 'Create a new campaign' and details the specific side effects: writing to data/plans/<id>/post-plan.json and registering as active. This clearly distinguishes it from sibling tools like plan_create_post or campaign_set_active.

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

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

The description implies this is used to create a new campaign, but does not provide explicit guidance on when not to use it or alternatives. Given the large number of sibling tools, such guidance would be helpful, but the intent is still clear.

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

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

Given annotations already declare the tool is neither read-only nor destructive, the description adds value by explaining the manifest and scheduler behavior. It does not mention side effects or permissions but is sufficient for understanding the tool's effect.

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 core action and immediately followed by a clarifying behavioral note. Every sentence adds value with no redundancy or fluff.

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

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

For a simple toggle tool with no output schema, the description covers purpose, effect, and a key behavioral nuance. It is nearly complete, though it could briefly mention error cases like invalid campaign ID.

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

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

Schema description coverage is only 25% (clientId has a description), yet the tool description does not explain the meaning of 'id', 'actor', or 'active' beyond implying 'active' is the toggle. The description fails to compensate for the low coverage, leaving parameter semantics unclear.

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 uses specific verbs 'activate/deactivate' and clearly identifies the resource as 'a campaign in the manifest', distinguishing it from siblings like campaign_create and client_set_active. It also explains the behavioral implication for scheduling.

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

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

The description provides clear context for when to use the tool (to toggle campaign active status) and indirectly explains that inactive campaigns are still reachable via explicit targets. However, it does not explicitly list when not to use or name alternative tools.

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

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

Annotations already mark destructiveHint=true. The description adds specific details: deletes override JPEG and post.cover field, and explains that render-sibling JPEG becomes cover. No contradiction with 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?

Single sentence, front-loaded with the action, and no unnecessary words. Every phrase adds value.

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 explains what the tool does and its effect, but lacks information about error conditions (e.g., post has no cover override), return values, or idempotency. Given no output schema, some additional context would be beneficial.

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

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

Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional semantic meaning beyond the schema definitions.

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

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

The description clearly states the action ('Remove a post's cover override') and identifies the specific resource and effect. It distinguishes from sibling 'set_cover' by implying reversal.

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 context is implied (reverting a cover override) but no explicit when-to-use or when-not-to-use guidance is given. No alternatives are mentioned despite sibling 'set_cover'.

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 indicate destructiveHint=true and readOnlyHint=false. The description adds critical behavioral details: it's reversible, requires owner and confirm, cannot archive the active client, and leaves credentials untouched. No contradiction with 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?

Three concise sentences, each providing essential information without redundancy. The main action is front-loaded, and every sentence adds value (reversibility, constraints, exclusions). No wasted words.

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

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

The description covers the main action, constraints, preconditions (owner, confirm), edge case (refuses to archive active client), and non-effects (credentials). No output schema is needed as the tool is a toggle with clear state change. The description is sufficient for correct invocation.

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

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

Schema description coverage is 75% (actor, confirm, clientId have descriptions; id lacks description but is obvious as target). The description reiterates the role of actor and confirm but does not add new parameter-level details beyond the schema. Baseline 3 is appropriate as schema does most of the work.

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

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

Description explicitly states 'Toggle a client between active and archived (reversible)', which clearly identifies the verb (toggle) and resource (client status). It distinguishes from sibling tools like client_set_active by indicating it toggles, and explicitly says it's reversible.

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

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

Provides explicit guidance: requires actor:'owner' and confirm:true, refuses to archive the currently active client (advises to switch first), and clarifies it never touches credentials. This gives clear when-to-use and when-not-to-use conditions.

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

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description reveals that it scaffolds a directory, never touches credentials, and is owner-gated with a confirm requirement. This adds valuable behavioral context for safe invocation.

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

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

The description is concise yet comprehensive, with each sentence providing distinct value: creation scope, constraints (owner, confirm), effect (scaffolding), safety (no credentials), and usage advice. No redundancy or filler.

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

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

For a tool with 8 parameters (3 required) and no output schema, the description covers creation details, constraints, and side effects. It omits return values, but the behavioral notes (e.g., scaffold path) mitigate this gap. Overall sufficient for informed use.

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

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

With 88% schema coverage, most parameters are already described. The description adds meaning by noting 'id slug', optional fields, and clarifying that clientId is not the target selector. This enhances the agent's understanding beyond the raw schema.

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

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

The description clearly states the tool creates a new client workspace with specific fields (id slug, displayName, optional logo/accent/timezone). It distinguishes from siblings by noting owner gating and advising against switching active client, making the tool's unique role evident.

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 specifies preconditions: actor must be 'owner' and confirm must be true, with fail-closed behavior. It provides guidance to prefer per-call clientId over switching active client, but does not explicitly list alternatives or when not to use this tool.

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

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

Annotations already indicate readOnlyHint=true, but the description adds significant behavioral context: it lists the exact fields returned, explains that schedulerRunning is a global flag and actionBlocked is per-client, and explicitly states 'No secrets.' This adds value beyond annotations.

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

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

The description is concise but packs essential information including output structure, field explanations, and usage notes. It is front-loaded with the purpose. Slightly longer than necessary but efficient.

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

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

Given no parameters and no output schema, the description is complete. It explains the output structure, field semantics, usage pattern, and safety (no secrets). There are no gaps.

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

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

The tool has zero parameters and schema coverage is 100%, so the description does not need to add parameter details. The baseline of 3 applies as the description provides no additional parameter information.

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

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

The description clearly states 'List the configured clients and the active one' with a specific verb and resource. It also explicitly distinguishes this tool from siblings like client_create and client_archive by noting that creating/switching/archiving is not an agent 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?

The description provides explicit guidance on when to use this tool and how to use the output: 'Pass clientId on any other tool to scope that one call to a specific client without switching the active one.' It also clarifies that certain operations are reserved for the dashboard.

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?

Describes behavioral traits beyond annotations: mutates global state, owner-gated, requires confirm:true, target must exist and be active, never touches credentials. No contradiction with 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?

Very concise, three to four sentences front-loading purpose and risks, no unnecessary words.

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

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

Given no output schema, covers what it does, prerequisites, constraints, and behavior. Lacks return value info but that's acceptable for a state-changing 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%, but the description adds clarification for clientId (not the target selector, accepted for parity only), adding value beyond the schema.

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

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

The description clearly states the tool switches the global active client, specifies owner-gating and required fields. It distinguishes from similar tools by warning about global state mutation and the risk of 'posted to the wrong client'.

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 advises preferring per-call clientId on other tools instead, indicating when not to use this tool. Mentions the risk of mutating global default state, providing clear context for usage.

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

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

Beyond the annotations (readOnlyHint=true), the description details that it never auto-retries or pokes blocked lanes, never fails wholesale (per-client degradation), and specifies what metaBlocked contains (booleans/counts only, no secrets).

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 well-structured, front-loading the purpose, then fields, then behavioral notes. Every sentence adds value, though slightly verbose with repeated 'metaBlocked' details; still overall concise and organized.

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

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

Given no output schema, the description fully explains the return structure (one row per client, field list) and error behavior (degrade per client). It covers all necessary context for a complex roll-up 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 schema covers the single parameter (horizon) with a full description. The description adds no new semantic information beyond the schema's definition, meeting the baseline for high coverage.

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

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

The description clearly states it is a 'Cross-client roll-up of pending/overdue work, scheduler state and the Meta-368 breaker', enumerates the response fields, and distinguishes from single-client siblings like client_list.

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 explicitly states it is read-only, iterates all clients (no clientId arg), and explains the horizon parameter. It implies usage for an overview but does not explicitly mention when not to use or list alternatives, though context from siblings makes it clear.

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

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

Adds significant context beyond annotations: owner requirements, confirmation flag, optimistic concurrency, error on stale revision, and assurance that credentials are untouched. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).

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 convey purpose, fields, constraints, and error behavior with no fluff. Information is front-loaded and every part earns its place.

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

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

Covers input and constraints well but lacks output description (no output schema). The return value on success/failure is implied but not stated. Still, the description is adequate for typical use.

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

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

With only 44% schema coverage, the description compensates by explaining immutable id, required role/confirmation, ifRev usage, and the non-target nature of clientId. This adds crucial meaning missing from the schema.

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

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

The description clearly states the action ('Update') and resource ('client's non-secret profile'), listing specific fields (displayName, logo, accent, timezone). It distinguishes from siblings like client_create and client_archive by focusing on profile updates only.

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

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

Provides explicit constraints: owner-gated (actor:'owner', confirm:true), requires ifRev from client_list for concurrency, and notes stale rev returns 'stale_write'. Does not explicitly state when not to use or suggest alternatives, but the context is clear.

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

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

The description goes well beyond annotations by detailing what fields are included (identifiers, posting variables) and explicitly stating what is excluded (token values), plus noting the return of a rev for optimistic concurrency. No contradictions with 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 sentences with no wasted words. The main action is front-loaded, and the structured enumeration in parentheses is efficient and readable.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description provides a complete summary of return content, including the rev field. The annotations handle the read-only hint, and the description covers the rest sufficiently.

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

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

Schema description coverage is 100% for the single parameter clientId, so the baseline is 3. The tool description does not add any additional meaning about the parameter beyond what the schema already provides, thus no extra 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?

The description uses the verb "Read" and specifies the resource "pendpost configuration", listing included and excluded fields clearly. It distinguishes itself from siblings like config_set by being read-only, and the detailed enumeration of identifiers, variables, and secrets provides precise scope.

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 explicitly states this is for reading configuration and includes "Read-only" at the end, making the use case clear. It does not explicitly mention when not to use it or name alternatives like config_set, but the context is strong enough for an agent to infer correct usage.

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

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description explains that writing occurs via a 'whitelisted, hardened writer' and affects specific files (.env and config.json). It clarifies that secrets cannot be set here, adding important behavioral context.

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

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

The description is well-structured with a clear main sentence, followed by important caveats and parameter format. While slightly verbose, each sentence contributes useful information without redundancy.

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

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

Given the absence of an output schema, the description should mention expected return values or success indicators. It also lacks details on whether changes take effect immediately. However, it covers the core inputs and behavior adequately.

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 75%, and the description adds value by detailing the structure of the 'set' parameter as { identifiers?: {...}, posting?: {...} } and explaining that ifRev comes from config_get. However, the required 'actor' parameter has no documentation in either schema or description, slightly reducing completeness.

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

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

The description clearly states 'Edit NON-SECRET config only' and specifies identifiers and posting variables, distinguishing it from secret setting which is explicitly forbidden. The verb 'Edit' and resource 'NON-SECRET config' are specific and 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?

Provides explicit guidance on when to use (non-secret config) and when not to use (secrets), with an alternative method for secrets via CLI. Also specifies prerequisite of obtaining ifRev from config_get, indicating a recommended workflow.

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 indicate destructiveHint=true and readOnlyHint=false. The description adds critical context: confirmation-gating, in-use protection, deletion of sibling cover, dangling plan rows behavior, and specific error categories (needs_confirm, invalid_input). No contradiction with annotations.

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

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

The description is a single dense paragraph that front-loads the primary action and covers all essential behaviors. It could be slightly more structured (e.g., bullet points for error conditions), but it remains concise and informative with no wasted words.

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

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

Despite lacking an output schema, the description covers return behavior (errors) and side effects (cover deletion, dangling rows). For a destructive tool with 4 parameters, it provides comprehensive context for safe 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 has 100% coverage with descriptions for all 4 parameters. The description reinforces key constraints: file basename (no path segments), actor logging, and the confirm parameter's role. It adds clarity beyond the schema without redundancy.

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

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

The description clearly states 'Delete one media file from data/media (the asset library), including its paired .jpg cover sibling.' This is a specific verb and resource, and the mention of the cover sibling distinguishes it from other asset operations like rename_asset or asset_upload.

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 explains when deletion is allowed (no references) and when it requires confirm:true (in-use). It also lists rejection conditions (path segments, leading dots, disallowed extension). It does not explicitly contrast with alternatives like plan_delete_post, but the context is sufficient for the agent to decide appropriate use.

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

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

The description claims 'Read-only platform calls' but annotations set readOnlyHint=false, creating a contradiction. Beyond that, it mentions storing results in pendpost state but does not detail side effects, auth requirements, or rate limits.

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

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

The description is relatively concise with two sentences and a clause, but includes technical details about engine commands that could be streamlined.

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 moderately complex with no output schema, and the description does not describe what metrics are returned or the format of results, leaving a gap in completeness.

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 both parameters ('campaign' and 'clientId') have descriptions in the schema. The description adds no additional meaning beyond what the schema provides.

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

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

The description clearly states it 'fetches fresh platform metrics for published posts' and lists specific platforms (IG, FB, YouTube, LinkedIn) and the commands spawned, making the purpose very specific and distinct from siblings.

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

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

The description implies usage for obtaining fresh metrics and mentions the scheduler's 24h sweep, but does not explicitly state when to use this tool versus alternatives, nor what conditions to avoid.

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 description reinforces the readOnlyHint annotation, mentions locale-awareness and honesty about gaps ('no metrics yet'), and specifies it reads from stored metrics and plan state. No contradictions with annotations.

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

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

The description is a single sentence that front-loads the purpose and then lists contents. It is efficient but could be slightly more structured for readability. No wasted words.

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

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

Without an output schema, the description adequately describes the output as locale-aware markdown with specific sections. It covers the essential information an agent needs to understand what the tool returns.

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

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

Schema coverage is 100% with a single optional parameter (clientId) already described in the schema. The tool description does not add additional meaning beyond what is in the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool renders a performance digest with specific contents (published posts with metrics, queue health, etc.). It distinguishes itself from sibling tools by being a read-only digest generator, and the verb 'Render' plus resource 'performance digest' is specific.

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

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

The description implies the tool is for generating a comprehensive digest of recent performance, but it does not explicitly state when to use it versus alternatives. However, given the unique functionality and no sibling digest tool, the usage context is clear.

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

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

Annotations provide readOnlyHint=true, and the description adds that each probe is read-only and never publishes, plus Meta probe is skipped during a 368 block. It also discloses the return format. This provides useful behavioral context beyond the annotation.

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 four sentences, front-loaded with the core action, and each sentence adds necessary detail. There is no redundancy or wasted words.

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

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

Given the absence of an output schema, the description includes the return format { ok, health }. However, it does not describe error scenarios or what happens if a probe fails, which could be useful for a complete understanding.

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% (baseline 3). The description adds meaning by explaining that platform parameter is optional and, if provided, re-probes only that lane; if absent, all lanes are probed. This clarifies parameter behavior beyond the schema.

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

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

The description clearly states the tool runs live liveness probes per platform and stores results in pendpost state. It specifies the verb ('Run', 'store'), the resource ('liveness probe', 'pendpost state'), and distinguishes from siblings like pendpost_health by mentioning the specific storage location and read-only nature.

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

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

The description implies usage for credential health checks but does not explicitly state when to use or not use this tool. No alternatives are mentioned, so the agent lacks guidance on choosing between this and related tools like pendpost_health or platform_validate.

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 description goes beyond annotations by detailing specific behaviors: sets status:posted, leaves queue, never triggers real publish, never mints platform id, optionally records externalUrl. This fully discloses the tool's effects without contradiction to annotations (readOnlyHint=false, destructiveHint=false).

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 two sentences with no wasted words. It front-loads the core purpose and then adds behavioral details. Every sentence adds essential 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?

Given the complexity (5 parameters, no output schema, partial schema coverage), the description covers purpose, behaviors, and one parameter. It omits explanation of required parameters and does not mention return values, but the names suffice for basic use. Slightly more detail on output would improve completeness.

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

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

With only 40% schema description coverage, the description compensates partially by mentioning the optional externalUrl parameter. However, it does not describe the required parameters (actor, postId, campaign) or clientId beyond the schema. The parameter names are self-explanatory, but more detail would improve clarity.

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

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

The description clearly states the verb 'Mark' and the resource 'planned post', specifying it's for posts published natively outside Pendpost. It distinguishes from sibling tools by emphasizing it does not trigger a real publish or mint a platform id, which sets it apart from approve_post, publish_due_run, etc.

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

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

The description provides clear context for when to use the tool: when a planned post was published externally. It explicitly states what the tool does not do (never triggers real publish, never mints platform id), guiding against misuse. However, it does not explicitly name alternative tools like approve_post for when the post is published internally.

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 indicate non-read-only and non-destructive. The description adds valuable behavioral context: the tool writes to a file, cadence and pause settings are independent, resuming does not clear blocks, and the env var META_PUBLISHING_PAUSED overrides the file. This goes beyond what annotations provide. No contradictions with annotations.

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

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

The description is front-loaded with the main purpose and is relatively concise given the complexity. Every sentence provides necessary information about behavior, parameters, and edge cases. Minor redundancy could be trimmed, but overall it is well-structured and informative.

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

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

Given the tool's complexity (nested cadence object, multiple optional params, env var interaction, and co-existence of settings), the description covers all key behaviors. It explains the independent nature of cadence and pause, the env var override, and the need to clear blocks separately. There is no output schema, but the tool likely returns a simple success/error, so that's acceptable. A mention of return value would be a minor improvement.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning: it explains that maxPer24h must be >=1 and cannot be disabled, minGapMinutes >=0, that cadence and pause can be set independently, and the effect of the env var on the paused parameter. It also clarifies that actor is required and logged. This adds significant value beyond the schema.

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

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

The description clearly states the tool's purpose: 'Set the Meta (Facebook/Instagram) publishing lane: tune the anti-ban cadence cap and/or pause/resume the lane.' It specifies the verb 'Set' and the resource 'Meta publishing lane', and distinguishes between the two main actions (tuning cadence and pausing/resuming). This differentiates it from sibling tools like 'pendpost_record_block' (for clearing blocks) and 'publish_*' tools.

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

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

The description provides clear context on when to use this tool: to set the cadence cap or pause/resume the lane. It also notes important nuances: cadence and pause co-exist in one file, resuming does not clear Meta-368 blocks (pointing to an alternative), and the env var override. However, it does not explicitly state when not to use this tool versus alternatives like 'pendpost_record_block' or 'scheduler_set', but the context is sufficient.

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 include readOnlyHint=true, and the description confirms read-only behavior. It adds value by detailing the output fields (ready, blockers, schedulerRunning, nextDue) and the nature of blockers (global vs per-post). This goes beyond the annotation's safety declaration, though it could be more comprehensive about edge cases.

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 concise, front-loaded with the tool's purpose ('One-call readiness check'), and uses a structured format with curly braces to denote the return object. Every sentence adds information with no fluff.

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

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

Although there is no output schema, the description outlines the return structure sufficiently for basic usage. It covers the key outputs and the scope of checks. However, it could be more precise about the exact shape of blockers and nextDue entries. Overall, adequate for a tool with few parameters and clear purpose.

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

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

Schema coverage is 100%, so the schema already describes horizon and clientId. The description implicitly references horizon via 'next N due posts' but does not add substantial new meaning. Baseline 3 is appropriate as the schema handles parameter documentation.

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

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

The description clearly states it is a one-call readiness check (SS-10) that returns a structured object with ready, blockers, schedulerRunning, and nextDue. It specifies that it checks global blockers and per-post blockers for upcoming posts, and explicitly marks it as read-only. This distinguishes it from sibling tools like health_recheck or other status tools.

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

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

The description implies it's a quick 'one-call' overview, but does not explicitly state when to use this versus more detailed tools like health_recheck or other post-specific checks. It provides clear context for what it checks, but lacks exclusionary guidance.

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

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

Discloses important behavioral traits beyond annotations: the block stays active until explicitly cleared, blockedUntil is not an auto-expiry but a recorded-at anchor, and clearing requires out-of-band confirmation. Annotations only indicate non-read-only and non-destructive.

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

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

The description is a single paragraph of four sentences, front-loaded with purpose, then usage and detail. Every sentence is necessary and no fluff. Well-structured for agent comprehension.

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

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

Given the tool's complexity (8 parameters, no output schema), the description covers the key use case, parameter semantics, and clearing procedure. Minor omission: no mention of return values or side effects beyond skipping the Meta lane, but this is acceptable without an output schema.

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

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

Schema covers all parameters (100% coverage), but the description adds significant meaning to the key parameter 'blockedUntil' by explaining its semantics (anchor vs expiry) and how to clear the block with null. This adds value beyond the schema.

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

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

The description clearly defines the tool's purpose: to record a Meta action block (error 368) so pendpost and the scheduler skip the Meta lane. It is specific and distinct from sibling tools, which include related but different tools like meta_lane_set and pendpost_health.

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

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

Provides explicit usage guidance: 'Use immediately when any Meta publish fails with error code 368 - and never retry the publish.' Also explains when to clear the block and how, making it clear when not to use the tool (i.e., don't retry).

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 annotations (readOnlyHint=false, destructiveHint=false), the description adds that it creates drafts, that approval requires a different actor, and includes constraints for YouTube and LinkedIn posts. It does not mention idempotency or error conditions, but the additional context is valuable.

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 somewhat verbose but structured with key information front-loaded (the draft requirement) and grouped into required/optional/specific rules. It could be more concise, but each sentence provides necessary detail for a tool with many options.

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

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

Given the tool's complexity (nested object, multiple optional fields, platform-specific rules) and no output schema, the description covers the main points: required parameters, optional fields, constraints for YouTube and LinkedIn. It does not describe return values or error handling, but the core functionality is well-documented.

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 description adds significant meaning beyond the schema by specifying allowed values for post.type (reel|story|video|text|youtube-short|youtube-longform), explaining the purpose of link and image for LinkedIn text posts, and detailing character limits for YouTube description and tags. This compensates for the schema coverage of 75%.

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

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

The description clearly states 'Create a new post in a campaign' with a specific verb and resource, and distinguishes itself from siblings like plan_update_post and approve_post by stating it always creates as a draft.

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 explicitly says 'ALWAYS as a draft (approval can only be flipped by approve_post from a different actor)', providing clear guidance on when to use this tool vs approve_post, and implying it should not be used for approval.

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 indicate destructiveHint=true, and description adds key behavioral context: refusal for published posts without force, and confirmation that no platform data is removed. No contradiction with 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 sentences, no wasted words. Front-loaded with action and key constraints.

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

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

Covers major behavioral trait (handling published posts) but lacks detail on all parameters. No output schema, so return behavior is not explained, but for a delete tool this is acceptable.

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 low (40%) with only force and clientId described. Description only adds meaning for force (required true for published posts), leaving actor, campaign, and postId unexplained both in schema and 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?

Description clearly states the action ('Delete a post row from its plan') and resource. It distinguishes from siblings like plan_create_post and plan_update_post by specifying it deletes rows and handles publish evidence.

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?

Description explains when to use the force parameter (when post has publish evidence) and clarifies that deletion does not affect platforms. Lacks explicit mention of alternatives among siblings, but context is clear.

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

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

Annotations already provide readOnlyHint=true, and the description reinforces 'Read-only'. It adds behavioral context by listing what data is returned (captions, schedule, platforms, etc.) and the optional postId parameter. No contradictions exist, and the description enriches the understanding beyond the annotation.

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 two concise sentences, front-loaded with the primary action. Every word provides value; there is no repetition or fluff. The structure is efficient and clear.

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

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

Given the tool's simplicity (3 params, read-only, no output schema), the description adequately explains the return content by listing attributes. However, it does not cover potential error conditions or ordering, but for this use case it is largely complete.

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

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

Schema coverage is 100%, so each parameter (postId, campaign, clientId) already has a description. The description adds value by mentioning 'full normalized posts' and optional single post, but clientId is not referenced. Per guidelines, baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the verb 'Get' and the resource 'full normalized posts of one campaign', listing specific components like captions, schedule, platforms, etc. It distinguishes from sibling tools like plan_list by specifying that it retrieves posts for a campaign, not a list of campaigns, and allows optional single post retrieval via postId.

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

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

The description implies usage when full details of posts are needed, but it does not explicitly state when to use this tool over alternatives like plan_list or plan_create_post. No when-not-to-use or alternative comparisons are provided, so the guidance is only implicit.

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?

Description reinforces the readOnlyHint annotation by stating 'Read-only' and adds details on the specific data returned, providing useful behavioral context beyond the annotation.

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?

Single sentence, no wasted words, front-loaded with the action and resource. All information is relevant and concisely expressed.

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

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

Given the simple single-parameter schema and read-only annotation, the description fully covers what the tool does and what it returns. No gaps for an agent to misunderstand.

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 one parameter fully described. The description does not add any parameter-level detail beyond the schema, so baseline score of 3 is appropriate.

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

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

Description clearly states the tool lists all social campaigns (plan files) and specifies the returned fields (per-state post counts, next due post, schedulerRunning, manifestError). It is distinct from sibling tools like plan_get which retrieves a single plan.

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

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

No guidance on when to use this tool versus alternatives, nor any prerequisites or restrictions. The description only states what it does without contextualizing its usage.

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

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

Discloses key behaviors beyond annotations (readOnlyHint=false, destructiveHint=false): optimistic concurrency retry logic, null-means-remove semantics, and platform-specific field requirements. No contradiction with 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?

Packed with essential info in a structured way, front-loading the purpose and field list. Slightly lengthy due to platform specifics, but no wasted sentences.

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?

Covers main behaviors, constraints, and error handling for a mutation tool without output schema. Missing return value description but mentions possible 409 error, which suffices.

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?

Adds meaning beyond schema: explains ifRev for concurrency, lists updatable fields for the 'fields' parameter, and notes character limits for description/tags. Schema coverage is 50%, so description compensates well.

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

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

The description clearly states it updates owner-editable fields of a post, lists them explicitly, and crucially specifies which fields it NEVER updates (approval/cover/publish-result), distinguishing it from sibling tools like approve_post or set_cover.

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

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

Provides clear when-to-use context: optimistic concurrency via ifRev, how to handle 409 errors, and constraints per platform (e.g., YouTube title/description, tags length). Does not explicitly contrast with other update tools but is implicit given domain specificity.

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 description adds context beyond the readOnlyHint annotation by detailing the types of checks performed and the return structure. However, it does not disclose external API calls or side-effect behavior, but given the annotation, this is acceptable.

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 concise sentences: first enumerates checks, second specifies return format and read-only nature. Every sentence adds value with no redundancy.

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

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

Given the tool's complexity (3 params, no output schema), the description covers the purpose and return shape well. However, it could be more specific about what problems are returned and whether it checks all platforms.

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 description does not explain the parameters 'postId', 'campaign', or 'clientId' beyond the context of 'one post'. With only 33% schema description coverage, the description adds minimal value to parameter understanding.

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

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

The description clearly states the tool validates per-platform readiness of one post, listing specific checks (media, caption length, credentials, auth, etc.) and the return format. It distinguishes from siblings like 'validate_media' which likely focuses only on media.

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 not explicitly state when to use this tool versus alternatives like 'validate_media' or 'brand_lint'. There is no guidance on prerequisites, when not to use it, or which checks take precedence.

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?

Despite annotations having destructiveHint false, the description accurately notes that this publishes real content, implying state changes. It adds essential context about the Meta 368 block and the need for explicit instruction, compensating for the lack of behavioral detail in annotations.

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

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

The description is two sentences, front-loaded with the main action, followed by critical warnings. No unnecessary words, highly efficient.

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

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

Given the tool's complexity (sweep action with optional scoping and safety guard) and the lack of annotations, the description fully covers purpose, usage, behavior, and parameter constraints. No gaps remain for the agent to infer.

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 baseline is 3. The description adds value by explaining that 'postId' requires a campaign and that 'confirm' must be true as a guard, enhancing understanding beyond schema.

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

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

The description clearly states the tool runs a publish-due sweep that spawns engines for due/approved posts, with optional scoping. It uses specific verbs and resource, distinguishing it from siblings like 'approve_post' or 'mark_posted'.

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 explicitly states when to call it (only on owner's instruction) and when not to (never during a Meta 368 block). It also requires confirm: true, providing clear usage boundaries.

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 readOnlyHint annotation, the description adds extensive behavioral details: it reports readiness but never publishes, never spawns an engine, never writes, and describes how blockers like Meta-368 are surfaced. This transparency helps the agent understand exact 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?

The description is informative and well-structured, starting with the core purpose and then detailing the response shape and constraints. It is slightly verbose but every sentence adds value, making it efficient for an AI agent.

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?

Without an output schema, the description fully explains the return value structure and common blockers (like approval issues, missing media, Meta-368). It also clarifies edge cases, making the tool's behavior predictable.

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 inline descriptions for each parameter. The description does not add any additional semantics beyond the schema, so baseline 3 applies.

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

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

The description clearly identifies the tool as a read-only publish preview/dry-run, specifying exactly what it reports (which posts would fire, lanes, modes, blockers). It distinguishes itself from the sibling publish_due_run by stating it never publishes, never spawns an engine, and never writes.

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 explicitly positions the tool as a dry-run for previewing readiness, and contrasts with the actual publish action (never publishes). While it doesn't explicitly name alternatives, the context of siblings and the clear side-effect statements provide strong usage guidance.

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

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

The description adds the 'optional note' and 'same actor rules' beyond annotations, which already indicate a non-read, non-destructive operation. It does not detail side effects, permissions, or response behavior, but is consistent with annotations.

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

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

The description is two sentences, efficiently conveying purpose and a key rule. No redundancy or fluff; front-loaded with the main action.

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 covers the core action and a key behavioral rule, but lacks details on prerequisites, return values, or error scenarios. For a write operation with 5 parameters and no output schema, it is adequate but not comprehensive.

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

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

Schema coverage is only 20% (only clientId described). The description mentions 'optional note' which matches the note parameter, but does not explain the other required parameters (campaign, postId, actor). It adds minimal value beyond the schema.

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

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

The description clearly states the action (reject a post), the approval status set (rejected), and the optional note. It distinguishes itself from the sibling approve_post by referencing 'Same actor rules as approve_post', making the purpose 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?

The description implies usage for rejecting posts with an optional fix note, and references approve_post for actor rules, which gives context. However, it does not explicitly state when to use this vs. other tools or when not to use 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?

The description provides extensive behavioral context beyond annotations: sanitizeAssetName runs on both names, extension cannot change, no overwriting, confirm-gated for in-use files, and missing source is invalid_input. This fully compensates for the lack of annotation detail.

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

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

The description is relatively long but well-structured, starting with the main action then detailing constraints. Every sentence adds value, though a bulleted list could improve readability.

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

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

Given 5 parameters, no output schema, and complex behavior (sanitization, overwrite protection, confirm-gating), the description covers all edge cases and expected outcomes comprehensively.

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

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

Schema coverage is 100%, so baseline is 3. However, the description adds meaningful context like same extension requirement and sanitization logic, raising the score above baseline.

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

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

The description clearly states 'Rename one media file within data/media, renaming its paired .jpg cover sibling to match.' It uses a specific verb (rename) and resource (media file), and distinguishes from sibling tools like 'delete_asset' or 'set_cover' by focusing on renaming.

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 not explicitly state when to use this tool versus alternatives like 'delete_asset' or 'validate_media'. It implies usage for renaming but lacks comparative guidance, though constraints (no extension change, confirm-gated) indirectly hint at appropriate scenarios.

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 set 'destructiveHint' to false, but the description states that for natively-scheduled posts, 'their platform object [gets] deleted', which is a destructive action. This is a direct contradiction between description and annotations, resulting in a low score.

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

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

The description is concise with two sentences, front-loading the core action ('Move a post to a new scheduledAt') and explaining the variants efficiently. No unnecessary words.

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

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

Given the tool has 6 parameters (4 required) and no output schema, the description covers the key behavioral differences and the confirm requirement. However, it does not mention any return values or side effects beyond the deletion, leaving some gaps for a complete understanding.

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 low at 33%, and the description adds meaning for the 'scheduledAt' parameter (ISO datetime) and the 'confirm' parameter (required for natively-scheduled). Other parameters like 'actor', 'postId', 'campaign', and 'clientId' are not elaborated beyond the schema, so the description provides moderate additional 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?

The description clearly states the tool moves a post to a new scheduledAt (ISO datetime), and distinguishes the behavior for waiting-due versus natively-scheduled posts, which aligns with the tool name 'reschedule' and differentiates it from siblings like 'unschedule'.

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 explains the context-dependent behavior (waiting-due vs natively-scheduled) and highlights the requirement for 'confirm: true' in the natively-scheduled case. However, it does not explicitly state when not to use this tool or mention alternatives among siblings.

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

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

Annotations declare not read-only and not destructive. Description adds behavioral context: persisting across restarts, 60s tick, and condition for publishing. No contradiction.

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?

Single 20-word sentence, front-loaded with action, no wasted words.

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

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

For a simple tool with 2 params and no output schema, description covers core behavior, persistence, and publishing condition. Lacks return value info but annotations suffice.

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?

50% schema coverage; description does not elaborate on parameters like 'running' or 'clientId' beyond their names. Schema has description for clientId but not running. Description adds no param-specific help.

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?

Description clearly states the verb 'Start or stop' and resource 'in-process publish scheduler', with specific details like '60s tick over active campaigns' that distinguish it from siblings like publish_due_run.

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

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

Implies use for starting/stopping the scheduler but provides no explicit guidance on when to use vs. alternatives or when not to use 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?

The description states the tool materializes files and writes post.cover, which is a destructive action. However, annotations set destructiveHint=false, creating a contradiction. The description does not reconcile this, so transparency is poor.

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 composed of two long sentences that are dense but clear. It front-loads the main action and includes all necessary information without excessive verbosity. Minor improvement could be splitting into shorter sentences.

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

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

Given the tool has 6 parameters (2 required) and no output schema, the description fully explains the action, parameter roles, side effects (file materialization), and return value (applicability map). It leaves no critical gaps.

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

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

Schema coverage is 100%, and the description adds value by explaining usage contexts for frameSec, filePath, and base64, including a size constraint. It clarifies the relationship between parameters and the cover source.

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

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

The description clearly states the tool sets a cover override for one post, listing three methods (frameSec, filePath, base64). It is specific and distinguishes it from siblings like 'clear_cover'.

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 explains when to use each method (e.g., extract frame from media, upload local file, or base64 bytes). It implicitly guides the agent on selection but lacks explicit exclusions or when-not-to-use guidance.

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

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

Annotations (readOnlyHint=false, destructiveHint=false) already indicate mutation without destruction. The description adds value by specifying platform refresh behaviors and the interactive re-auth hint on expiry, but fails to disclose side effects like token invalidation or rate limits.

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

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

Two sentences, front-loaded with the main action. No wasted words, though the second sentence could be split for clarity. Suitable length.

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

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

No output schema is provided, and the description does not explain what the agent should expect as a return (e.g., new token, success message). Given the tool's mutative nature and lack of return documentation, completeness is lacking.

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 covers both parameters (clientId optional, platform enum) at 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema, only confirming which platforms are refreshable.

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

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

The description clearly states the tool refreshes a platform token, naming specific refreshable platforms (linkedin, x) and distinguishing from others (Meta, YouTube). The verb 'refresh' and resource 'token' are precise, and there are no sibling tools with similar function.

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

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

The description implies when to use (token refresh needed) but offers no explicit guidance on when not to use or alternatives. It mentions some platform-specific behaviors but no comparative usage advice.

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 mark the tool as destructive, but the description adds context by explaining the mechanism: setting executionMode to parked and deleting native platform objects with a confirm flag. This goes beyond the basic annotation, though it could further clarify the post's final state.

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

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

The description is extremely concise at two sentences, each earning its place. The first sentence defines the core action, and the second addresses a critical nuance. No superfluous text.

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

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

Given the tool's moderate complexity (5 parameters, destructive behavior), the description covers the main action and key nuance. It lacks information on error conditions (e.g., if confirm is false when required) and the post's final state, but it is largely sufficient for an AI agent to understand the tool's effect.

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

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

With 40% schema description coverage, the description adds significant value by explaining the 'confirm' parameter's purpose ('Required true when a native platform object must be deleted'). However, it does not clarify other required parameters like actor, campaign, or postId, which rely on the schema's minimal descriptions.

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

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

The description clearly states the tool's purpose: 'Take a post off the schedule'. It distinguishes between general unscheduling (setting executionMode to parked) and handling natively scheduled posts where the platform object is deleted. This specificity helps differentiate from sibling tools like plan_delete_post or reschedule.

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 not provide explicit guidance on when to use this tool versus alternatives like reschedule or plan_delete_post. It implies usage through the description of behavior but lacks a direct comparison or conditional advice.

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 provide readOnlyHint=true, but the description adds specific behavioral details: uses ffprobe, checks resolution/codec/faststart/duration, and targets specific aspect ratios for story and feed. No contradictions with 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?

Description is a single, efficient sentence that front-loads the main action and includes key details. No redundant information.

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

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

For a read-only probing tool with 3 parameters and no output schema, the description explains what it does but lacks details on output format, error conditions, or how results are presented. Adequate but not comprehensive.

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

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

Schema description coverage is only 33% (only clientId has a description). The tool description does not elaborate on postId or campaign parameters, leaving their meaning and format ambiguous. Given low coverage, the description fails to compensate.

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?

Description clearly states verb ('Probe'), resource ('one post's local media file'), and specific checks ('resolution/codec/faststart/duration spec checks for 9:16 story / 4:5 feed'). It distinguishes from siblings like platform_validate and verify_post by specifying local file probing with ffprobe.

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 context (spec checks for story/feed aspect ratios) and declares read-only, but does not explicitly state when to use this tool versus alternatives like platform_validate or verify_post. No exclusions or prerequisites are mentioned, leaving usage guidance implicit.

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?

Description claims the tool is a 'pure read' and uses a read-only verify subcommand, but annotations set readOnlyHint=false, creating a contradiction. According to the rubric, this scores 1. The description otherwise provides detailed behavioral info.

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?

Description is well-structured and front-loaded, with each sentence adding value. It could be slightly more concise but is not 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?

Description explains the state transition (verified-live or verify-failed) and mentions writing a non-destructive block, which is useful. However, with no output schema, it does not specify the return format or what the agent receives after invocation, leaving some gaps.

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

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

Schema description coverage is only 25% (only clientId has a description). The tool description adds no specific parameter semantics; it only gives general context. With low coverage, the description should compensate but 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?

Description clearly states the tool reads a post back from platforms to confirm it is live, distinguishing it from mutation tools like approve_post or mark_posted. It emphasizes that it never publishes, mints an id, or mutates status, which differentiates it from sibling tools.

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

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

Description explicitly states when to use (after hand-off to confirm live) and what it does not do (pure read, never publishes, etc.). It also notes that Meta is read even while its lane is paused, providing context. However, it does not list alternative tools or when not to use.

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

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

Goes well beyond annotations: states change is real and immediate, requires confirm:true to apply, probe is read-only access-tier check, engine checks handle matches. Discloses local file path requirements.

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

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

Four dense sentences, no fluff. Front-loaded with purpose, then critical usage constraints, then parameter details. Every sentence earns its place.

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

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

For a complex tool with 10 parameters and no output schema, the description covers purpose, behavior, constraints, and parameter semantics thoroughly. No gaps remain for an AI agent.

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 good descriptions. The description adds extra semantics: character limits (bio <=160), image dimensions (400x400, 1500x500), confirm guards, probe behavior. Baseline 3, plus 1 for added 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?

The description clearly states the tool edits the X profile and lists all editable fields (name, bio, url, location, image, banner). It distinguishes from siblings by noting it's account-level, not a post.

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 states 'only call it on the owner's explicit instruction', explains probe vs confirm semantics, and notes the engine refuses if handle doesn't match. Provides clear when-to-use and when-not-to-use guidance.

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