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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds non-obvious behavior beyond that: skips are silent rather than an error, published content is untouched, and a whole fanned-out group must be passed together. It does not describe the returned result (counts vs. ids), which is the remaining gap.

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

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

Three short sentences, no filler, with the primary action and its scope constraint front-loaded and the group caveat last. Every sentence carries distinct 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 two-parameter destructive mutation with no output schema and full annotation coverage, the description supplies the critical caveats an agent needs (unpublished only, silenceskips, unfixable). Only the response shape on partial cancellation is left unstated, a minor omission given there is no output schema to lean on.

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 postIds and workspaceId are already documented, establishing the baseline of 3. The sentence 'Pass every id in a fanned-out group to cancel it whole' adds semantic meaning the schema does not carry: the ids are not independent and partially-cancelled groups are an intended usage pattern.

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

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

States a specific verb (Cancel) plus resource (posts) and narrows scope to 'posts that have not published yet', so an agent can tell it apart from reschedule_posts or delete_video_job without opening a schema. The parenthetical about fanned-out groups further pins down what 'a post' means operationally.

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

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

Clearly bounds the situation: only unpublished posts can be cancelled, anything published or mid-publish is skipped, and unpublishing is not possible. That gives the agent a when-not condition, but no named alternative is offered (e.g. reschedule_posts for moving a live post), so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write/safety profile is covered; the description goes beyond that by disclosing that creating reserves allowance and that nothing is published until publish_automation runs. That reservation side effect is exactly the kind of non-obvious behavior worth surfacing, though it doesn't say whether the reservation is reversible or how to release it.

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

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

Three tight sentences, zero padding, and the most decision-relevant fact (it plans, it does not publish) is front-loaded. Every sentence carries distinct 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 nine-parameter mutation with full annotation coverage and no output schema, the description covers sequencing, side effects, and the dependency on whoami. The gap is that it never indicates what comes back (e.g. an automation identifier) even though the very next step, publish_automation, presumably needs it — a notable omission for an output-schema-less chained tool.

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

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

Schema description coverage is 100%, so the schema already documents all nine parameters, including the postTimes constraint against automationSlotsPerDay. The description only echoes that constraint and adds the whoami lookup pointer, adding little meaning beyond the structured fields — 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 gives a specific verb and resource ('Plan a run of posts across a date range... creates the plan'), and immediately scopes what the tool does not do by naming the sibling that completes the action ('does not publish anything until publish_automation is called on it'). An agent can distinguish create_automation from publish_automation, update_automation, and schedule_rush_lineup without opening any schema.

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

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

It supplies real preconditions: read automationSlotsPerDay from whoami before choosing postTimes, and the create-then-publish sequence is spelled out. It stops short of enumerating the other alternatives (update_automation, schedule_rush_lineup, list_automations) or saying when an existing automation should be updated instead of a new one created.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the write-safe posture is covered structurally. The description adds only framing ('to organise media into') and says nothing about duplicate-name handling, required scoping, or effects on existing folders.

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

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

A single short sentence with the action front-loaded; nothing is wasted. It is efficiently sized, though brevity here edges toward under-specification rather than crisp completeness.

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

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

For a simple two-parameter create tool with annotations and a fully documented schema, the description is minimally adequate. It omits what happens on duplicate names and how folders relate to library uploads, which would round out an agent's 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 description coverage is 100%, so both parameters (name, workspaceId) are already documented in the schema. The description adds no format, naming-constraint, or scoping detail beyond that, so the baseline 3 applies.

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

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

States a specific verb (Create) and resource (library folder), making the operation immediately identifiable. However, it does nothing to distinguish itself from siblings like list_folders or move_uploads_to_folder beyond the obvious verb.

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

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

The description offers no when-to-use guidance, no prerequisites, and no mention of related tools such as list_folders or move_uploads_to_folder. An agent gets no help deciding between folder operations.

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

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

Annotations already declare readOnlyHint=false and openWorldHint=true, but the description adds the non-obvious credit-cost model: LLM-written copy plus one generated image per slide, so cost scales with slide count. That is real added value beyond the structured fields, though it omits whether the call is async or how long a 12-slide run takes.

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

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

Three short sentences, front-loaded with the purpose, then the cost warning, then the prerequisite lookups. Every sentence carries distinct information with no filler.

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

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

Covers purpose, cost, and prerequisites well, but with no output schema the description never says what the call returns or how to retrieve the finished slideshow (get_slideshow exists as a sibling). For a six-parameter, credit-consuming creation tool, that return-path gap is meaningful.

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

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

Schema coverage is 100% and the schema descriptions already name list_studio_models and list_slideshow_templates as the sources for imageModel/imageTier/setId, so the description's pointers largely restate existing schema text. No extra semantics on brief, slides bounds, or workspaceId beyond what the schema says.

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

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

States a specific verb (build) and resource (slideshow) plus the scope constraint that it comes from built-in template sets. This clearly separates it from siblings like generate_image, generate_video, and get_slideshow, which produce or fetch different artifacts.

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

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

Gives concrete routing guidance: fetch image model/tier ids from list_studio_models and valid set ids from list_slideshow_templates before calling. It stops short of stating when NOT to use this tool (e.g., vs. generate_image for a single asset), but the prerequisite chain is explicit and actionable.

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 false, destructiveHint false), the description discloses a plan-limit failure mode and the fact that creation does not auto-switch the active workspace. It does not cover permissions or return format, but the key behavioral traits are present.

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

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

Three short, front-loaded sentences cover purpose, failure behavior, and follow-up workflow with no filler. 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 one-parameter create tool with no output schema and clear annotations, the description supplies purpose, failure mode, and next-step guidance. Nothing critical for correct invocation is missing.

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

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

Schema description coverage is 100% and the single name parameter is fully documented in the schema. The description adds no parameter-level semantics, so the baseline of 3 is appropriate.

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

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

The description gives a specific verb+resource ('Add a workspace') and clarifies what a workspace is (a separate brand with its own content and connected accounts). It distinguishes the tool from the sibling use_workspace by explicitly saying it does not switch to the new workspace.

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

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

It explicitly states a when-not condition ('Does not switch to it') and names the follow-up tool ('call use_workspace afterwards'), which helps an agent sequence calls correctly. However, it does not spell out the trigger for creating a new workspace versus using an existing one, leaving that to inference.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is established structurally. The description adds meaningful context beyond the annotations: scheduled items are cancelled, published posts remain, and the action is irreversible ('No undo'). It doesn't cover auth or side effects on workspace, but it goes well past the annotation baseline.

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

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

Three short, front-loaded sentences with zero waste. The action is stated first, the persistence scope second, and the irreversibility last as a caution — well ordered and appropriately sized.

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

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

No output schema exists, but for a delete operation the meaningful return is success/failure, which the description doesn't address. It does cover the key behavioral concerns (cascade cancellation, irreversible). The only real gap is what the caller receives.

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 both parameters are documented in the schema itself, setting the baseline at 3. The description adds no parameter-level detail such as whether workspaceId scoping affects the automation lookup, so it does not exceed the schema's contribution.

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

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

States a specific verb (Delete) and resource (automation) immediately, distinguishing it from siblings like cancel_posts or delete_video_job. The scope of what deleting entails is made concrete rather than abstract.

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 a destructive action with no undo, which guides the agent toward caution, but it never names alternatives or says when to delete vs. cancel/pause. In a sibling set full of cancel_posts and update_automation, no routing guidance is given.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description earns credit for going beyond them: it specifies permanence ('No undo'), that published posts survive, and that anything still referencing the file loses it. It stops short of stating permission requirements or whether references block or merely break the delete.

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

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

Three short sentences, front-loaded with the action, then consequences, then the irreversibility warning. Every sentence carries distinct information with no redundancy.

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

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

For a 2-param destructive tool with no output schema, the description covers the essential behavior an agent needs: what is destroyed, what survives, and that it cannot be undone. It omits error/precondition behavior (e.g., whether a still-referenced upload is rejected) and permission needs, which keeps it from a 5.

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% - uploadId and workspaceId are both documented in the schema, including a pointer to list_library_uploads. The description adds nothing about parameters, so the baseline 3 is appropriate.

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

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

States a specific verb and resource ('Permanently delete one piece of library media') plus the scope of effect ('free its storage'). An agent can distinguish this from the other delete_* siblings (delete_workspace, delete_video_job, delete_automation) without opening any schema.

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

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

Usage is implied by the consequence language ('Posts already published with it are unaffected') but the description never says when to reach for this tool versus alternatives or what preconditions exist (e.g., must the upload be unfolder'd first, or is there a bulk delete). There is no delete sibling for uploads, which softens the gap, but the routing 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?

Annotations only give destructiveHint=true; the description adds the crucial nuance that credits already spent are NOT refunded and that deletion removes the result, not the charge, plus 'No undo'. This is real behavioral context beyond what the structured fields disclose and directly informs the decision to call it.

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

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

Three short, front-loaded sentences: purpose first, then the charge/undo caveat. Every sentence earns its place with no filler.

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

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

No output schema exists, and for a destructive delete tool the description covers the essentials: what is destroyed, the financial consequence, and irreversibility. What an agent needs to call this correctly is present.

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

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

Schema description coverage is 100%, so both jobId and workspaceId are already documented by the schema (including that jobId comes from list_video_jobs). The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Delete a generated video and its clip'), with the scope clarified by 'and its clip'. It is trivially distinguishable from siblings like get_video_job or delete_upload, and an agent can tell what is removed without opening the schema.

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

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

The description implies this is the irreversible removal path ('No undo') but never states when to reach for it versus alternatives or prerequisites (e.g. jobId source is left to the schema). Usage is deducible from the verb but not explicitly guided.

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 confirm destructiveHint=true but do not say anything about irreversibility; the description adds that there is no undo and no export, specifies the full cascade of destroyed resources, and discloses a built-in refusal rule for the last workspace. That is rich behavioral context beyond the structured fields.

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

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

Three sentences, front-loaded with the destructive scope, then the irreversibility, then the precondition. No filler and every clause carries decision-relevant 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 single-parameter destructive tool with annotations covering the safety profile and no output schema, the description supplies the cascade, irreversibility, refusal behavior, and confirmation requirement. Nothing an agent needs before calling is missing.

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

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

Only one parameter and schema description coverage is 100% — the schema already explains workspaceId comes from list_workspaces. The description adds no format, ID, or resolution detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (delete) with an emphasized scope modifier (PERMANENTLY) and enumerates exactly what else is destroyed: reels, uploads, scheduled posts, analytics, connected accounts. This distinguishes it clearly from sibling delete tools like delete_upload or delete_automation at a glance.

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

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

Gives concrete preconditions and guardrails: confirm the exact workspace name first, and note that the last workspace cannot be deleted. It does not explicitly point to alternatives (e.g. use_workspace or rename_workspace) but the destructive scope plus the confirmation instruction gives clear when-to-use context.

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

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

Annotations declare destructiveHint=true, but the description goes well beyond that by specifying what survives ('already-published posts stay'), what breaks ('anything still scheduled to it will fail'), and the recovery path (user must redo OAuth in the browser). That is precisely the side-effect detail an agent needs before a destructive call.

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

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

Three short sentences, front-loaded with the action and immediately followed by consequences. Every sentence carries distinct information with no repetition of the title or schema.

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

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

For a destructive, no-output-schema tool, the description covers action, blast radius, irreversibility, and the recovery requirement. Nothing material for correct invocation is missing, and return values are not needed since no output schema exists.

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

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

Schema description coverage is 100% – both accountId and workspaceId are documented in the schema, including the accountId source ('from list_connected_accounts') and workspaceId defaulting behavior. The description adds no parameter-level detail beyond that, so the baseline of 3 applies.

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

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

The description names a specific verb and resource ('Disconnect a social account from this workspace') and adds the second effect ('revoke the app's access with the platform'), so the agent knows exactly what the call does. No sibling tool performs disconnection, so there is no ambiguity to resolve.

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

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

Usage is implied by the consequences spelled out (scheduled posts will fail, OAuth required to reconnect), which helps an agent decide whether to call it. However, there is no explicit when-to-use statement or named alternative, and no prerequisite conditions (e.g. permissions) are given.

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

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

Annotations only say readOnlyHint=false and openWorldHint=true; the description goes well beyond that by disclosing the credit cost range (1-24), that charges apply even if the result is unused, and that the call returns images synchronously with no polling. These are the exact behavioral traits an agent needs before spending credits.

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

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

Three sentences, cost warning front-loaded before the prerequisite lookups and the polling clarification. Every sentence carries distinct, non-redundant information with no filler.

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

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

With no output schema, the description still tells the agent what comes back (images immediately, no job to poll), what it costs, and which sibling tools supply valid argument values. Nothing needed to invoke this correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including the references route constraint and count cost multiplier. The description only echoes the sourcing advice for model/tier/aspect, adding no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource ('Generate images from a prompt') and is immediately distinguishable from the sibling generate_video. The synchronous-return note further pins down what this tool is versus job-based siblings like get_video_job.

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 routes the agent to list_studio_models for valid model/tier/aspect values and to whoami for balance checks before calling, and contrasts the flow with job-polling tools ('there is no separate job to poll'). When-to-use and prerequisite sequencing are both spelled out.

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

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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true) by disclosing credit pricing per second, the charged-on-accept-not-on-success rule, and the asynchronous background-render lifecycle. These are exactly the traits an agent cannot infer from structured fields.

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

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

Front-loads the cost warning, then the workflow sequence (source values, check balance, poll results). Every sentence carries actionable information with no filler.

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

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

Despite no output schema, the description explains the return (a job that renders in the background) and how to retrieve results via get_video_job. Combined with cost, prerequisites, and lifecycle coverage, nothing essential for correct invocation is missing.

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

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

Schema coverage is 100% and the schema already documents each parameter, including sourcing (model from list_studio_models, quality as the main cost lever, duration from durations). The description mostly repeats the sourcing hint rather than adding new syntax or constraint detail, so the baseline 3 applies.

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

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

States a specific verb and resource ('Start a text-to-video generation') and is clearly distinct from siblings like generate_image and get_video_job. An agent can identify this as the async video-generation entry point without opening the schema.

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

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

Explicitly names prerequisites and alternatives: pull valid values from list_studio_models, check balance with whoami first, and poll results with get_video_job. It tells the agent both what to do before and after, leaving nothing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. Against that lower bar the description still contributes by disclosing the shape of what comes back (totals, daily series, per-platform, top posts, posting-hour patterns) in the absence of an output schema, though it says nothing about pagination, cost 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, zero filler, and the payload contents are front-loaded before the routing guidance. Every clause earns its place.

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

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

With no output schema the description usefully enumerates the return composition, and all three params are documented in the schema. The only gap is not relating this tool to get_post_analytics, a sibling an agent may equally need to choose between.

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

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

Schema description coverage is 100% and the schema already explains range, timezone (including the 'rarely what the user means' guidance) and workspaceId. The description adds no parameter-level detail beyond that, so the baseline 3 is correct.

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

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

The description names a specific verb+resource ('performance for the workspace') and enumerates the exact content returned: totals, daily series, per-platform breakdown, top posts and posting-hour patterns. It explicitly distinguishes itself from the sibling get_dashboard, so an agent can route without opening either schema.

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

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

It gives an explicit routing rule with the alternative named: 'Use this over get_dashboard when the question is about trends, what performed best, or when to post.' That covers when-to-use and the alternative, but it omits the other obviously relevant sibling, get_post_analytics, and never states the inverse (when get_dashboard is preferable).

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds genuine context by disclosing the return shape (planned items with their individual states), but says nothing about permissions, missing-id behavior, or pagination.

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

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

A single front-loaded sentence covering scope and payload with no filler. Every clause earns its place.

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

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

With no output schema, the description carries the return-value burden and does sketch the payload (planned items and their states), which is more than most getters offer. It is still thin on what an agent should do with a bad or unknown automationId, but it is adequate for a simple read tool whose safety profile is annotation-backed.

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

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

Schema description coverage is 100%, so both workspaceId and automationId are fully documented in the schema, including the default for workspaceId. The description adds no parameter-level detail, which matches the baseline of 3 when the schema does 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?

It states the resource (a single automation) and scope ('one automation in full'), clearly distinguishing this from the sibling list_automations. It also names what the response contains (planned items and their states). It lacks an explicit verb, but the get semantics are unambiguous from the name and phrasing.

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

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

No when-to-use guidance is given: nothing says to call this after list_automations to drill into a specific automation, nor when to prefer get_automation over list_automations. The only routing hint (the id comes from list_automations) lives in the schema, not the description.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), so the bar is lower. The description adds real value beyond them by disclosing the return payload (website, description, voice settings) and its downstream role, which the annotations cannot convey. It omits any statement about empty/unset brand handling or permission requirements.

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

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

Two sentences, front-loaded with what the tool returns before the usage rationale. The second sentence is long but each clause earns its place by naming the consuming tools and the failure mode avoided. No filler or redundancy.

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

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

For a read-only, single-optional-parameter tool with no output schema, the description compensates by enumerating the returned fields and explaining their purpose. An agent knows what it will get back and why it should call it before writing copy; nothing material is missing.

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

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

There is a single optional parameter (workspaceId) with 100% schema description coverage, so the schema fully documents its default and per-call override behavior. The description adds nothing about the parameter, which is the expected baseline when the schema does the heavy lifting.

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

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

The description names a specific resource ("the workspace's brand") and enumerates its contents: website, description, and voice settings (brand name, @handle, niche, default platform, mention behavior). It is clearly a read operation, implicitly contrasting with the write-oriented sibling update_brand_voice, though it never names that sibling explicitly.

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

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

It gives explicit when-to-use guidance: "read it before writing copy so the result sounds like the brand rather than like a generic ad," and states which downstream consumers depend on it (caption writer, UGC prompt builder). No when-not condition or named alternative (e.g., update_brand_voice) is given, so it stops short of a full routing rule.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), so the bar is lower. The description adds genuinely useful behavioral context beyond them: sections degrade independently and an 'unavailable' marker means only that section failed while the rest of the payload stays valid — key for interpreting partial results.

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

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

Three tight sentences, front-loaded with the payload contents before the usage hint and the degradation caveat. No filler, no repetition of the title.

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

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

With no output schema, the description usefully doubles as a return-value summary by enumerating the sections and explaining the partial-failure semantics. It is nearly complete for an agent's needs; only deeper section schemas or pagination limits are unaddressed, and those are minor for a read-only dashboard.

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

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

Schema description coverage is 100%, so both parameters (timezone, workspaceId) are already thoroughly documented in the schema, including field-level advice about UTC defaults. The description adds no parameter detail, so the baseline 3 applies.

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

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

The description names a specific resource ('the workspace at a glance') and enumerates exactly what it returns: lifetime views/likes, published count, the last five reels with status, and what's scheduled next. This content list clearly distinguishes it from siblings like get_analytics or get_post_analytics, which are narrower drill-downs.

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 best first call for "how am I doing"' gives clear usage context and positions it as an entry point. However, it never names alternatives or states when NOT to use it (e.g., use get_analytics for deeper breakdowns), so guidance stops short of explicit routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so safety is covered. The description adds real behavioral context beyond them: metrics are per-post and may include a time series 'where snapshots exist', disclosing that trends are conditional and not always available.

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

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

Two tight sentences with no padding: the first defines the output, the second defines the trigger. The routing condition is placed after the purpose, keeping the key subject front-loaded.

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

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

For a two-parameter read tool with no output schema, the description covers what the metrics are, that trend data is snapshot-dependent, and when to reach for it. It could say more about what a snapshot gap means for the response, but nothing essential to invoking the tool correctly is missing.

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

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

Schema description coverage is 100%, so both parameters are already documented, including that postIds come from list_posts and workspaceId defaults to the active workspace. The description's 'by id' phrasing adds nothing the schema doesn't already say, so the baseline 3 applies.

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

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

States a specific verb+resource ('Metrics for specific posts by id') and immediately scopes it to per-post rather than workspace-wide, which is exactly the distinction the agent needs against get_analytics. The added note about movement over time further sharpens what kind of metrics are returned.

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

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

Gives an explicit trigger ('Use after list_posts when the question is about particular posts rather than the workspace as a whole'), which effectively routes the agent away from the workspace-level analytics tool. It stops short of naming that sibling tool outright, but the condition that selects this tool is unambiguous.

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

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

Annotations only mark this as non-read-only and open-world; the description supplies the genuinely non-obvious consequences — cards are counted against the daily reel allowance the moment they are in hand, and stay counted until kept or skipped. That consumption-then-resolution lifecycle is exactly the kind of side-effect disclosure annotations cannot express.

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

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

Three short sentences with zero padding: purpose first, then the cost/allowance warning, then the action guidance. The most decision-relevant fact (cards count against quota) is front-loaded right after the purpose.

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

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

With no output schema, the description still covers what an agent needs: what it returns conceptually (cards), the quota side effect, the required follow-up tool, and the user-consent expectation. Nothing material is missing for a 3-optional-parameter tool.

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

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

Schema description coverage is 100%, so mode, cursor, and workspaceId are already documented inline (including the fresh/repeat enum semantics and the 'start at 0' cursor hint). The description adds no parameter-level detail beyond a vague 'large batch' phrasing, so the baseline 3 applies.

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

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

States a precise verb+resource ('Deal the next cards from the Rush deck') and immediately clarifies what kind of operation it is: 'NOT a plain read'. It also names the companion tool resolve_rush_item, which separates it from look-alikes such as get_rush_prefs.

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

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

Gives explicit operating guidance: ask the user before dealing a large batch, and resolve what you deal. It routes the agent to resolve_rush_item for the follow-up step, so both when-to-use and the downstream obligation are stated rather than inferred.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so safety and repeat-call semantics are covered. The description contributes one piece of context beyond that — that the values reflect the deck's *current* live tuning — but says nothing about freshness, caching, or what happens when no preferences are set.

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

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

A single front-loaded sentence with no filler and no repetition of the title. It is efficient, though the em-dash clause is slightly cryptic for someone unfamiliar with what a 'Rush deck' is.

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

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

With no output schema, the description carries the burden of sketching the return value; it partially does so ('content mix and the categories it draws from') but never enumerates the shape. For a zero-required-parameter read tool this is adequate but leaves the agent guessing at the response fields.

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 workspaceId parameter, which already documents that it defaults to the active workspace. The description adds no additional meaning about scoping or defaulting, so the baseline 3 applies.

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

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

The description concretely names the resource (the Rush deck's current tuning) and enumerates what it covers — content mix and source categories — so an agent knows it reads preference/configuration state. It lacks an explicit verb like 'get' and never contrasts itself with nearby siblings such as get_rush_feed or schedule_rush_lineup, keeping it short of a 5.

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

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

There is no statement of when to call this versus alternatives, even though the sibling list contains get_rush_feed, resolve_rush_item, and schedule_rush_lineup, which are the obvious confusable tools. The description only says what the payload is, leaving the choice entirely to inference.

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

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

Annotations already declare readOnlyHint, openWorldHint and idempotentHint, so the safety profile is covered. The description adds genuine behavioral value by disclosing what the response contains (slides, their copy, their images) — important since no output schema exists.

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

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

A single short sentence with the resource and payload contents front-loaded; there is no filler or repetition of the title.

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

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

For a simple two-parameter read tool with full schema coverage and no output schema, the description adequately covers both what it fetches and what comes back. Only minor gaps remain, such as error behavior when an id is invalid.

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

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

Schema description coverage is 100%, so both slideshowId and workspaceId are already documented in the schema, including where the id comes from. The description adds no parameter-level meaning beyond that, making the baseline 3 appropriate.

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

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

States a specific resource (one slideshow) and scope (in full), including the payload contents (slides, copy, images). It implicitly contrasts with the plural sibling list_slideshows via 'One slideshow', but never names an alternative explicitly.

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

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

Usage is only implied: the singular 'One slideshow' suggests this is the detail-fetch counterpart to list_slideshows. There is no explicit when-to-use statement, no prerequisite (e.g. obtain the id first), and no exclusion guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, and the description adds genuinely new behavioral context: the state machine values, the expected latency (tens of seconds to minutes), and a recommended poll cadence. With no output schema, it also discloses what the call yields ('the clip when it has finished'), though it says nothing about how failed jobs report errors or whether results expire.

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

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

Two compact sentences with zero waste; the return value is front-loaded and the operational advice follows. Every clause carries information an agent would otherwise have to guess.

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 poll tool with no output schema, the description covers what is returned, the state transitions, and timing expectations. It is close to complete; only failure-mode detail and any result-retention limits are missing.

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

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

Schema description coverage is 100%, so both jobId and workspaceId are already documented in the schema, including jobId's origin in generate_video. The description adds no parameter-level detail beyond that, making the baseline 3 appropriate.

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

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

States a specific verb and resource ('current state of one video generation') and enumerates the possible states (queued, running, done, failed) plus the finished-clip payload. This clearly separates it from the plural list_video_jobs and the generating sibling generate_video.

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

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

Gives concrete polling guidance ('poll every 10-15 seconds rather than in a tight loop') and the schema ties jobId to generate_video, so the agent knows when this tool is the right call. It does not explicitly name list_video_jobs as the alternative for enumerating multiple jobs, so it stops short of full when/when-not routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered by structured data. The description adds genuinely useful domain semantics (approval workflow, scheduled publishing) that help interpret results, but says nothing about ordering, pagination, or whether drafts/active/completed automations are all returned.

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

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

Two short sentences, front-loaded with the resource scope and then the concept definition. The opening fragment is telegraphic but nothing is wasted; the definition sentence earns its place by clarifying the object being listed.

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

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

For a zero-required-param read-only list with no output schema, the description covers what an automation is but not what a listing returns (fields, filters, empty-state behavior). Adequate for a simple list, but an agent cannot predict result shape from the description alone.

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

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

There is a single optional parameter with 100% schema description coverage, so the schema already explains workspaceId and its default behavior. The description adds no parameter-level detail, which is the expected baseline when the schema does 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?

The description names the resource (automations) and scoped it to the workspace, and the second sentence gives a precise definition of what an automation actually is — a planned run of posts over a date range with human approval then scheduled publishing. It does not explicitly contrast with the single-item sibling get_automation, so it is clear but not fully differentiated.

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

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

There is no statement of when to use this tool versus alternatives such as get_automation (single item) or list_posts. The workspace scoping is implicitly handled by the optional workspaceId param, but no usage context or exclusions are provided.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond them: connections are scoped per workspace, and this call cannot initiate OAuth. It does not describe return shape or pagination, but for a simple read that gap is minor.

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

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

Three short sentences, front-loaded with what is returned, then scope, then the OAuth constraint. No sentence is redundant and nothing is buried.

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

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

For a read-only, single-parameter list tool with no output schema and full annotation coverage, the description supplies what an agent needs: the platforms, the per-workspace scoping, and the inability to connect accounts. Only the return format is left unspecified, which is acceptable here.

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 100% schema description coverage on the single workspaceId parameter, the schema already documents defaulting and per-call override behavior. The description's 'Connections are per workspace' reinforces the parameter's meaning but adds no syntax or format detail, so the baseline of 3 is appropriate.

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

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

States a specific resource (TikTok, Instagram and YouTube accounts connected to this workspace) and its scope, so an agent immediately knows what it returns. Enumerating the platforms and 'per workspace' scope distinguishes it from siblings like disconnect_account and from generic workspace 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 an explicit when-not: connecting new accounts can only happen in the browser and this tool cannot start an OAuth flow, which prevents a likely mis-invocation. It implies usage through 'the ids that scheduling tools need' but never names the sibling that would help route the agent further.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered structurally. The description adds only light domain context (folders are how library media is organised), but says nothing about pagination, ordering, or what an empty result means for a workspace with no folders.

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

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

A single short clause with zero filler and no repetition of the tool name. It is efficiently sized, though the terseness comes at the cost of the explicit verb.

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

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

There is no output schema and no annotations describing the payload, so the description should carry the burden of telling the agent what a folder record looks like (id, name, parent) and whether results are scoped to library media only. That information is entirely absent.

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

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

Only one parameter (workspaceId) and schema description coverage is 100%, so the schema already explains the default-to-active-workspace behaviour. The description adds no parameter detail beyond that, which is the expected baseline when the schema does 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?

Names the resource (folders) and ties it to a specific domain concept: the workspace's library media organisation. Combined with the tool name list_folders, an agent knows this returns the folders in a media library, distinguishing it from list_library_uploads and create_folder. It falls short of 5 only because the sentence is a noun-phrase fragment rather than an explicit statement of the listing action.

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

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

No when-to-use guidance and no alternatives named, despite many adjacent siblings (list_library_uploads, create_folder, move_uploads_to_folder). The agent must infer that this tool is for discovering folder IDs before creating or moving uploads.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds that results include the credit balance and are workspace-scoped, which is mild extra context but says nothing about ordering, freshness window, or pagination behavior.

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

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

One sentence of content plus one sentence of routing guidance, with the resource and workspace scope front-loaded. No filler, nothing redundant with the title.

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

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

For a read-only listing tool with full schema coverage and no output schema, the description supplies the essentials: what is listed, where, what fields come back, and why to prefer it over regenerating. Ordering/recency-window and pagination details are the only real omissions.

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

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

Schema description coverage is 100% and both parameters (limit, workspaceId) are documented there, including the default-workspace behavior. The description adds no syntax, format, or default detail beyond the schema, so the baseline 3 applies.

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

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

The description names a specific resource (image generation runs), scopes it (in this workspace), and enumerates the payload (prompts, images, credit balance). It also implicitly distinguishes itself from the sibling generate_image by positioning itself as the way to retrieve an earlier result instead of generating a new one.

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

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

"Use to find an earlier result rather than paying to regenerate it" gives an explicit when-to-use and the cost rationale that selects this tool over generate_image. It stops short of stating exclusions (e.g., how far back the history goes, or what to do if the run is not found).

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, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description's added value is the shape of what comes back (ids, titles, folders, storage keys) — genuinely useful given there is no output schema. However, it says nothing about scope, pagination, or whether all uploads are returned, which are the remaining behavioral unknowns.

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

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

Two tight clauses, front-loaded on the resource, with no filler sentences. The second clause about generation tools is the most valuable part and is placed last, which is a minor ordering weakness rather than bloat.

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

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

For a one-parameter read-only list tool with full annotation coverage and rich schema descriptions, the description supplies the missing piece — what the items contain and why the ids matter. Only pagination/scope behavior is unaddressed, which is a small gap given the tool's 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 description coverage is 100% for the single workspaceId parameter, whose default and meaning are documented in the schema itself. The description only gestures at workspace scoping ('in the workspace library') without adding format or default semantics. Baseline 3 is correct when the schema carries the parameter load.

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

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

States the specific resource (media in the workspace library) and enumerates its contents — uploaded clips and images, with ids, titles, folders, storage keys. That is far more than a restatement of the name. It stops short of explicitly differentiating itself from list-focused siblings such as list_folders or list_slideshows, relying on the noun 'library media' to do that work.

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

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

No explicit when-to-use or when-not-to-use statement, and no named alternative. The closing clause ('The ids here are what reference-taking generation tools expect') implies the usage pattern — fetch ids before calling generate_image/generate_video — but the agent has to infer that this is the look-up step rather than read it.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety semantics are covered. The description adds useful content context (what notification categories exist, and that results are 'recent' rather than exhaustive), but says nothing about volume, ordering, or how the paging cursor interacts with that recency window.

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

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

One tight sentence with the resource stated first, followed by content examples and the primary use case. No redundant clauses and nothing to trim.

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

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

For a single-optional-parameter read tool with no output schema, the description covers what comes back and why you'd call it. The only missing piece is return-shape detail (ordering, expected count), which is minor since the annotations establish it as a safe read.

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% — the single 'before' parameter already documents its ISO timestamp format and paging role. The description adds no format or usage detail for it, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific resource (notifications) scoped to the account and enumerates the concrete contents (finished renders, failed publishes, allowance warnings), which makes the tool's purpose unambiguous. It does not name the sibling mark_notifications_read as the contrasting operation, so sibling differentiation is left to inference.

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

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

Gives a clear when-to-use context: 'answering "did anything break" without reading every post.' There is no explicit exclusion or named alternative (e.g., mark_notifications_read), so it stops short of the 5-level routing guidance.

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

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

Annotations already declare readOnlyHint/openWorldHint/idempotentHint, so the safety profile is covered; the description adds genuinely new behavioral facts: a hard 500-row cap on most recent posts and the fan-out row semantics where one post per account shares a reel id and publish time. It doesn't address pagination beyond the cap, which is why this is a 4 rather than a 5.

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

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

Three dense sentences, all front-loaded: returned fields first, then the cap, then the duplication semantics that determine how rows must be interpreted. Nothing is padding.

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

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

With no output schema, the description carries the return-shape burden and does so by naming the fields each row carries. For a read-only, single-optional-param tool with annotations covering safety, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100% and there is a single optional workspaceId whose default ('active one') is already documented in the schema. The description's 'in the workspace' phrasing adds no syntax, format, or scoping detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Every post in the workspace') and enumerates the returned facets — captions, platforms, times, per-post metrics, account — which distinguishes it from siblings like get_post_analytics and list_slideshows. An agent can tell immediately this is the broad post inventory call.

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

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

Usage is implied by the scope statement ('every post ... published, scheduled, publishing and failed'), and the note that 'the scheduling tools treat that group as one unit' gestures at related siblings such as reschedule_posts and cancel_posts. However, it never explicitly says when to prefer this over get_post_analytics or other list tools, so guidance stays inferential.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds that results span both drafts and finished sets and are workspace-scoped, which is useful content-level context, but it says nothing about ordering/recency despite the 'Recent slideshows' title, nor about pagination behavior.

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

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

A single short sentence fragment with no filler, front-loading the resource and scope. It is appropriately sized, though being a bare fragment it carries no explicit action verb.

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 list tool with full schema coverage, annotations, and no output schema, the definition is nearly sufficient. The notable gap is that the title promises 'recent' ordering while the description never states sort order or recency semantics, leaving the agent to guess what the list returns first.

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 both parameters, so the schema already documents limit and workspaceId. The description's phrase 'in this workspace' loosely reinforces the workspaceId default but adds no syntax or format detail beyond the schema; baseline 3 applies.

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

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

The description names the resource (slideshows) and its scope (drafts and finished sets, in this workspace), but offers no verb — it is a noun phrase that only implies a listing operation. It never distinguishes itself from get_slideshow or list_slideshow_templates, so an agent must infer the difference from the tool name alone.

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

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

There is no statement of when to use this tool versus get_slideshow (single item) or list_slideshow_templates, and no prerequisites or exclusions. Usage is only implied by the 'list_' prefix in the name.

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

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

Annotations already cover read-only, open-world, and idempotent behavior, and the description adds that the result includes ids and intended purpose for each template. It stops short of broader behavioral details like ordering or empty-result handling, which is acceptable given the annotations.

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

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

One sentence, no filler, and it front-loads the resource and its connection to create_slideshow. Every clause contributes to identifying the tool and its output.

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 no-parameter list tool with annotations covering safety and no output schema, the description sufficiently explains what is returned (ids and purpose). It could be slightly more explicit about completeness or ordering, but no critical agent decision is left unaddressed.

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

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

There are zero input parameters, so parameter semantics are not applicable. Baseline 4 applies because the empty schema leaves nothing for the description to compensate for.

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

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

States the specific resource (template sets) and its relationship to create_slideshow, plus what is returned (ids and purpose). An agent can distinguish it from create_slideshow and other slideshow 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 use before create_slideshow by saying these are templates create_slideshow can build from, but it does not explicitly state when to call this list tool versus alternatives or any prerequisites. Usage is inferable but not spelled out.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), so the bar is lower; the description still adds non-obvious behavior: unknown model/tier ids are rejected and pricing varies substantially between tiers, which shapes how an agent should use the returned data. It does not describe ordering, pagination, or the shape of returned entries, which keeps it short of a 5.

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

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

Two sentences, front-loaded with what the tool returns followed immediately by the actionable call-order rule. Every clause earns its place; nothing is restated from the title or schema.

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

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

With no output schema, the description carries the burden of describing returns and does so explicitly (tiers, aspect ratios, durations, per-image/per-second credit cost). Combined with the call-ordering instruction against generate_image/generate_video, an agent has everything needed to invoke it correctly.

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

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

The tool takes zero parameters, so the baseline is 4. The description's mention of tiers, aspect ratios, durations, and credit costs refers to returned data rather than inputs, and adds no parameter meaning — correctly so, since there are none.

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

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

States a specific verb and resource ('the image and video models available') and enumerates exactly what each entry carries: tiers, aspect ratios, durations, and per-image/per-second credit cost. This cleanly separates it from sibling listers like list_slideshows and from the generation tools themselves.

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

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

Gives an explicit call-order directive ('CALL THIS BEFORE generate_image or generate_video') and the concrete reason: model and tier ids are not guessable and an unknown one is rejected. It even supplies a decision rationale (tier price differences are large enough to warrant deliberate choice), leaving nothing to inference.

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

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

Annotations already declare readOnly/idempotent/openWorld, so the bar is lower, and the description adds real return-content context (status, clips, and credit balance) that no output schema provides. It also explains the effect of completedOnly ('skip anything still rendering'), though it says nothing about ordering, recency window, or the default page size.

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

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

Two tightly written sentences: the primary purpose and payload are front-loaded, and the optional filter is mentioned last. No filler or repetition.

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

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

With no output schema, the description usefully summarizes the return payload, and all parameters are covered by the schema. Minor gaps remain: no recency window, default limit, or ordering behavior for a list that could be long.

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

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

Schema description coverage is 100%, so all three parameters are already documented; the description only restates completedOnly as 'skip anything still rendering,' which adds little beyond the schema's 'Only return finished jobs.' Baseline 3 applies when the schema does the heavy lifting.

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

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

The description states a specific verb+resource ('Recent video generations in this workspace') and even names the payload (status, clips, credit balance), so it is clearly a listing tool. It never names the sibling get_video_job, so an agent must infer the list-vs-single distinction from the plural phrasing rather than being told.

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

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

Usage is implied ('recent generations ... plus the credit balance') and the completedOnly note gives a concrete filtering scenario, but there is no explicit when-to-use, when-not-to-use, or pointer to get_video_job for a single job. Adequate but leaves routing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety and repeat-safety are covered. The description adds genuinely new behavioral context: the response marks the active workspace and reports the plan's workspace allowance, which is return-value information not covered by any annotation. It does not describe ordering or result-size behavior, hence not a 5.

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

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

Three sentences, each doing distinct work: what it returns, what a workspace is, and when to call it. The most decision-relevant content (every workspace, active one marked) is front-loaded with no filler.

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

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

With no output schema, the description usefully compensates by describing the returned content (all workspaces, active one flagged, allowance). Combined with the annotations covering the read-only/idempotent profile, an agent has enough to call it correctly. The one omission is a pointer to use_workspace for switching the active workspace, which would round out the multi-workspace workflow.

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

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

The tool takes zero parameters and schema coverage is 100%, so the baseline is 4 and there is no parameter semantics for the description to elaborate. It correctly adds no invented parameter guidance.

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

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

The description states a specific verb+resource with clear scope: 'Every workspace on the account,' distinguishing a full listing from the single-workspace siblings like use_workspace or get_brand. It also defines what a workspace is ('a separate brand: its own content, its own connected social accounts, its own analytics'), so an agent grasps the concept immediately. It stops short of naming a sibling to contrast against, which is the only thing keeping it from a 5.

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

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

'Check this before acting when the account might have more than one' gives a concrete trigger condition for calling the tool, which is unusually actionable for a list endpoint. There is no when-not guidance and no explicit pointer to the alternative for switching (use_workspace), but the context for use 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 declare this as a non-read-only, idempotent, non-destructive mutation with openWorldHint, so the safety profile is covered. The description adds only the two-mode behavior, not what gets persisted, whether the change is reversible, or any permission requirements.

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

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

A single front-loaded sentence that names the action first and the two modes second, with no filler or restatement of the title.

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

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

For a two-parameter, zero-required mutation tool with full schema coverage, no output schema, and annotations covering safety, the description is sufficient to invoke correctly. It could optionally note the typical list-then-mark flow, but nothing essential is missing.

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

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

Schema description coverage is 100% and both parameters are documented there, including that 'all' ignores 'ids'. The description echoes the same split without adding format, limits, or precedence detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (mark read) and resource (notifications), and distinguishes the two operating modes (specific ids vs all=true) clearly enough that an agent can pick it out from the sibling list_notifications. It does not explicitly contrast itself with list_notifications, so it stops short of a 5.

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

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

The description implies the two invocation paths ('specific ids, or all of them at once with all=true'), which is useful for choosing between parameters, but it offers no when-to-use context, no prerequisites, and no mention of alternatives or the list_notifications counterpart that usually precedes it.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, and the description usefully adds that moves are metadata-only with no re-upload or file changes — meaningful reassurance for a mutation. It stops short of covering failure modes (nonexistent folder, invalid upload ids) or permission requirements.

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

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

Two tight sentences, front-loaded with the primary action and immediately followed by the non-obvious null case. No filler or repetition of the title.

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

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

For a 3-parameter metadata mutation with full schema coverage and annotations, the description covers the essential behavior and the null sentinel. With no output schema, it could say more about what a successful move returns, but nothing needed to invoke the tool correctly is missing.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema, including folderId's null semantics and uploadIds sourcing from list_library_uploads. The description adds no syntax or format detail beyond that, making the baseline 3 correct.

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

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

States a specific verb (move), resource (library media), and destination (a folder), plus the inverse case (out of every folder via folderId=null). This is unambiguous against siblings like list_library_uploads, delete_upload, and create_folder.

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 null-folderId branch is explained, which implies the two modes of use, but there is no explicit guidance on when to prefer this over alternatives (e.g. delete_upload or create_folder) or any prerequisites such as needing the uploads to already exist in the library.

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

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description adds the crucial irreversibility semantics — posts go out to real accounts on their planned times with no further confirmation. That is exactly the behavioral context an agent cannot infer from the structured fields. No contradiction: publishing to live accounts is not a destructive data mutation.

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

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

Three short sentences, front-loaded with the action and the irreversible consequence, ending with the required procedural gate. The capitalized warning earns its emphasis given the stakes; no filler.

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

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

With no output schema, the description carries the burden of what happens on success and does so (posts publish at planned times). It leaves open post-call behavior such as failure/partial-publish handling or whether repeat calls re-publish, which would matter for a point-of-no-return operation.

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

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

Schema description coverage is 100% with only two params (workspaceId, automationId), both already documented in the schema. The description adds no format, default, or cross-parameter semantics, so the baseline 3 applies.

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

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

States a specific verb pair and resource: approve an automation's lineup and commit it to the publishing schedule. This is clearly distinguishable from sibling mutations like update_automation or schedule_rush_lineup without opening any schema.

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

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

Gives an explicit precondition and prerequisite: show the lineup from get_automation and get explicit user approval before calling. It names the sibling to use for the input step, though it does not contrast against other scheduling siblings (e.g. schedule_rush_lineup) or state 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 already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description goes beyond that by disclosing a non-obvious side effect: the new name is flagged as human-chosen and protected from a later brand scrape overwriting it. It still omits permissions, error cases, and whether the change is reversible.

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

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

Two short sentences, zero filler, and the core action is front-loaded before the secondary consequence. 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 two-parameter mutation with full schema coverage, no output schema, and annotations covering safety, the description is nearly sufficient. The only gap is the absence of any authorization or failure-mode context, which is minor given the structured fields already present.

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

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

Schema description coverage is 100%, so both parameters (workspaceId, name) are already documented in the schema, including the pointer to list_workspaces as the source of the id. The description adds no parameter-level syntax or format detail, so the baseline of 3 applies.

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

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

The description states a specific verb+resource ("Rename a workspace") that cannot be confused with the other workspace siblings (create_workspace, delete_workspace, use_workspace, list_workspaces). The second sentence adds a distinguishing side effect that further separates it from a generic update.

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

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

Usage is implied by the name and the rename semantics, but there is no explicit when-to-use guidance, no statement of when to prefer this over e.g. create_workspace or delete_workspace, and no mention of prerequisites such as workspace ownership or existing membership.

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

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

Annotations only declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true); the description goes well beyond them by disclosing atomic group semantics (three rows sharing one time must move together), a hard refusal mode on partial input, and a minimum-lead-time constraint on the new timestamp. These are failure conditions an agent cannot infer from structured data.

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

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

Three sentences, front-loaded with the purpose, then the critical constraint, then the state and timing limits. No filler, and dropping any sentence would lose a rule the caller needs.

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

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

With no output schema, the description could say more about what comes back on success (e.g., updated post state or confirmation), but it fully covers preconditions, atomicity, and refusal behavior for a mutation tool. Nothing critical for correct invocation is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description still adds value by explaining why postIds is a group (one post spanning three accounts is three rows) and by reinforcing the ~5-minute lead time already hinted at in the schema description.

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

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

States a specific verb and resource ('Change when a scheduled post publishes'), which clearly separates it from siblings like cancel_posts, list_posts, and schedule_rush_lineup. An agent can identify the operation without opening the schema.

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

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

Gives explicit preconditions ('Only works while the posts are still scheduled', 'the new time must be a few minutes out') and the exact invocation rule ('Pass EVERY id in the group'), with the consequence spelled out ('a partial list is refused'). It also points at list_posts as the source of ids, effectively routing the agent to the right sibling.

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

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

Annotations already declare the mutation/safety profile (readOnlyHint=false, destructiveHint=false), so the bar is lower, yet the description adds real domain behavior: 'keep' materializes a new artifact (a reel), and 'skip' releases a hold against the daily allowance — a quota side effect the annotations do not convey. It does not state whether a decision is reversible or what happens on a duplicate/already-resolved card, so it is not fully transparent.

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

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

Two sentences, no filler, and the core decision semantics are front-loaded before the workflow note. Every clause carries information an agent needs.

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

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

For a 3-parameter mutation tool with no output schema, the description covers the action, both outcomes, and the upstream feed relationship; the workspace default is handled by the schema. Missing only edge behavior (idempotency/re-resolution, error outcomes), which keeps it from a 5.

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%: itemId, decision (with enum), and workspaceId are all documented in the schema, including the keep/skip semantics. The description only restates the same keep/skip behavior in prose, adding no format or fallback detail beyond the schema, so the baseline 3 applies.

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

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

States a concrete verb+resource ('Decide a card that has been dealt') and names both outcome branches with their consequences ('keep' → reel, 'skip' → frees the hold). It also explicitly ties itself to the sibling get_rush_feed ('Every card from get_rush_feed should end up here'), so an agent can distinguish it without opening the schema.

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

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

The second sentence gives a clear usage condition: every card returned by get_rush_feed is expected to pass through this tool, which effectively defines the when and the upstream prerequisite. It stops short of stating when NOT to call it (e.g. cards already resolved, or whether a decision is final and re-decidable), so it is clear context without 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 only declare readOnly=false, destructive=false, openWorld=true; the description goes well beyond them by flagging that the action PUBLISHES PUBLICLY, that user confirmation is required, that the referenced generation must already be complete, and that multiple accountIds fan out as a single group. These are exactly the side-effect and blast-radius facts an agent needs before invoking.

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 tight sentences, front-loaded with the action and destination before the warnings. The public-publish warning is capitalized and placed early rather than buried, and no sentence is filler.

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

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

For a mutation tool with no output schema, it covers prerequisites, timing constraints, side effects, and fan-out behavior, so an agent can call it correctly. It stops short of describing failure behavior or pointing at cancel_posts/reschedule_posts for remediation, which would complete the picture.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: the publishAt minimum lead time, and the non-obvious semantics that selecting several accounts fans out to all of them as one group. It does not elaborate on caption or workspaceId, which the schema already handles.

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

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

States a precise verb (schedule) and resource (an already-generated video or image) plus the destination (connected social accounts). The word 'already-generated' distinguishes it from generate_video/generate_image, and 'to publish' distinguishes it from the sibling schedule_rush_lineup. An agent can pick it out of the sibling list without opening the schema.

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

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

Gives concrete preconditions — the generation must have finished, publishAt must be ~2 minutes out, and the user must be confirmed before calling. It does not, however, name competing paths (schedule_rush_lineup, publish_automation, or plain write_post_copy for text-only posts) so the agent must infer that this is only for scheduling finished media.

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

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

Annotations only declare readOnlyHint=false, destructiveHint=false, openWorldHint=true; the description adds that nothing is published, a draft automation is returned, and the deck is left intact on refusal, which is the real safety story for a write tool. It also discloses concrete refusal conditions (200-item cap, postTimes vs reelsPerDay, periodEnd window).

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?

Long, but front-loaded with the key constraints (publishes nothing, flow order) and every sentence carries a decision the agent must make. The flow list and refusal list are dense but not padded; a little tightening is possible but nothing is genuinely wasted.

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

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

Covers purpose, ordering, refusal conditions, defaults, and the approval gate for a complex write tool with no output schema. Nothing an agent needs to call this correctly appears to be missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds operational meaning the schema lacks: timezone must be passed because the saved account zone can fall back to UTC, startDate defaults to tomorrow, postTimes knows nothing about audience wake time, and the plan-window check applies to startDate only. It stops short of documenting every item field, but the important defaults are covered.

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

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

States a precise verb+resource ('Turn Rush cards you have already dealt into a dated plan') and explicitly distinguishes itself from siblings resolve_rush_item and create_automation by naming what each of those does instead. An agent can identify this tool without opening the schema.

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

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

Gives an ordered five-step flow, states when to call this tool relative to resolve_rush_item (step 2 before step 3, with the reason: a refusal leaves the deck untouched), and names the approval precondition for publish_automation. Explicit alternatives and exclusions throughout.

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

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

Annotations already declare destructiveHint=false and openWorldHint=true, so the agent knows this reaches outside the system. The description adds genuinely new information beyond that: it returns the extracted content and explicitly does not save anything, which resolves whether this is a mutation or a transient read.

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

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

Three short sentences, front-loaded with what the tool does, then when to use it, then the return/persistence behavior. Minor redundancy between "so the brand can be described from it" and "before writing copy or setting the brand," but nothing wasteful enough to impair scanning.

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

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

For a one-parameter, no-output-schema tool this covers the essentials: purpose, trigger condition, return shape, and the non-persisting nature. It could be stronger by noting failure behavior for unreachable URLs or whether summarisation is lossy, but nothing critical for correct invocation is missing.

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

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

With a single parameter and 100% schema description coverage, the schema already documents the url field including the https:// format requirement. The description adds no syntax, format, or constraint detail beyond that, so the baseline 3 applies.

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

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

The description pairs a specific verb set (fetch and summarise) with a clear resource (a website) and states the downstream purpose (describing the brand). This distinguishes it from siblings like get_brand or update_brand_voice, which operate on already-stored brand data rather than fetching external content.

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

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

"Use this when the user gives a URL and you need to know what the business actually is before writing copy or setting the brand" gives an explicit triggering condition and a workflow position. It stops short of naming an alternative tool or stating when not to use it, so it is clear context without 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=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds one genuinely non-obvious trait beyond that: updates do not retroactively affect already-published items. It still doesn't clarify partial-update semantics (only automationId is required, implying a patch-style merge), which would be the natural next disclosure.

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

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

Two short sentences, zero filler, with the mutation scope front-loaded and the caveat second. Nothing is redundant with the title or annotations.

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

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

For a 7-parameter mutation tool with no output schema, the description covers what can be changed and one important side effect. It omits what an agent would still want: whether unspecified fields are preserved, how removing an account or a post time is expressed, and whether changed schedules re-trigger anything. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters including formats (YYYY-MM-DD, HH:MM) and the workspaceId default. The description only restates the field groups generically ('name, schedule or target accounts') and adds no syntax or constraint detail, so the baseline of 3 applies.

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

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

States a specific verb ('Change') and resource ('an automation') and enumerates the editable surface: name, schedule, target accounts. An agent can distinguish it from create_automation, publish_automation, delete_automation and get_automation. It does not explicitly name those siblings, so it stops short of a 5.

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

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

There is no statement of when to pick this tool over publish_automation, create_automation or delete_automation, and no prerequisites or preconditions are given. The only conditional content ('Items already published are not affected') is a behavioral fact, not usage routing.

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

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

Annotations declare a non-destructive write (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds real value beyond them: explicit partial-update/PATCH semantics ("only the fields you send are changed") and a documented failure mode for the globally unique @handle with a suggested value returned. It stops short of stating permission requirements or whether changes are reversible.

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

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

Three short sentences, no filler, with the core action stated first and the failure behavior last. Sizing is appropriate for a six-parameter optional-field tool.

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

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

For a write tool with no output schema and all-optional parameters, the description covers patch semantics and one failure mode but omits what the call returns, whether a partially-sent update can clear a field, and any permission context. Adequate, with visible gaps.

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

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

Schema description coverage is 100%, so all six parameters are already documented in the schema, which sets the baseline at 3. The description reinforces the handle-uniqueness constraint and the partial-update contract but adds no field-level syntax or format 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?

"Change how captions sound" conveys a mutation of caption/brand styling but stays metaphorical and never says it edits the brand voice configuration (niche, brand name, handle, platform). The name and title carry more specificity than the description does, so an agent gets only an approximate sense of purpose.

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

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

There is no guidance on when to use this versus reading settings first (e.g., get_brand), no prerequisites, and no mention of when not to call it. The only implied usage is "change something," leaving routing entirely to inference.

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

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

Annotations only declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true). The description adds two non-obvious traits the annotations cannot convey: the setting persists for the remainder of the session, and it affects only this MCP connection, not the user's browser switcher — preventing a plausible wrong assumption about UI 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?

Three short sentences, zero padding. The purpose and its persistence scope lead, and the browser-vs-MCP clarification follows as the caveat it is.

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

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

For a one-parameter, session-scoped state setter with no output schema and annotations covering safety, the description covers what changes, how long it lasts, and what it does not touch. An agent has everything needed to call it correctly.

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

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

With one parameter and 100% schema description coverage ('Workspace id from list_workspaces'), the schema already carries the semantics. The description repeats the same origin hint without adding format, validation, or failure behavior, so the baseline 3 applies.

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

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

Specific verb (set/switch) plus resource (workspace) plus the exact scope it applies to: every later tool call for the rest of the session. That scope statement distinguishes it cleanly from siblings like list_workspaces, create_workspace, and rename_workspace, which are about enumerating or modifying workspace entities rather than pointing the connection at one.

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

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

It tells the agent where the argument comes from ('from list_workspaces'), which is genuine routing guidance toward a sibling. It does not state when not to call it or what happens if a switch is already in effect, so it stops short of explicit when/when-not framing.

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

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

Annotations already declare readOnly/idempotent/openWorld, so the safety profile is covered. The description adds genuinely new behavior: quota enforcement is server-side and failures occur instead of queuing, plus the default-workspace side effect. It stops short of describing return format or freshness.

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

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

Three sentences, each earning its place: contents first, then the call-before-generation guidance, then the default-workspace note. Front-loaded and dense without filler.

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

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

With no output schema, the description correctly carries the return-value burden by enumerating the account/plan/quota categories, and it covers the default-workspace behavior. It doesn't specify exact fields or units, but the level of detail is sufficient for an agent to decide to call it.

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

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

Schema description coverage is 100% and the single optional workspaceId is fully documented in the schema (default from use_workspace, account's first workspace, one-call override). The description adds no syntax or semantics beyond that, so the baseline 3 applies.

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

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

The description states a specific resource (the signed-in account) and enumerates exactly what it returns: plan, AI Studio credits, reels quotas, automated posts, workspace slots, storage. It also pins a distinct role — naming the default workspace other tools act on — which no sibling claims.

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

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

Explicit when-to-use: 'Call this before any generation,' with the reason (limits are server-enforced and exceeding jobs fail rather than queue). It doesn't compare against potentially overlapping siblings like get_dashboard or get_analytics, so it stops short of a full when/when-not treatment.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true, and destructiveHint=false, so the safety profile is already covered. The description adds genuinely new behavior: a quota cost ('Costs a small amount of the account's text allowance'), a specific failure mode (409 with remediation 'set a website first'), and an information asymmetry the agent cannot otherwise detect.

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

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

Four short sentences, front-loaded with purpose, then cost, then the blocking precondition, then the comparative rationale. No sentence is redundant and none repeats the schema or annotations.

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

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

With no output schema, the description should carry the return shape; it implies a caption plus hashtags are produced but does not say whether the copy is persisted to a post or returned for the agent to use, and does not cover idempotency. Prerequisites, cost, and failure mode are all covered, so the gap is modest.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters including the kind enum and the slideshow 'slides' array. The description adds no parameter-level detail (e.g., how 'scene' or 'overlay' influence the output), so the baseline 3 applies.

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

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

The description gives a specific verb and resource: 'Write a caption and hashtags in the workspace's brand voice for a piece of content,' which is more precise than the title 'Write a caption' (it also produces hashtags). No sibling tool writes captions, so differentiation is effectively automatic, but the description never names or contrasts a sibling, keeping this at a 4 rather than a 5.

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

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

It states an explicit preference rule ('Prefer this over writing captions yourself'), the reason for it (it reads the brand voice, which you cannot see in full), and a hard precondition ('Requires a brand on the workspace — without one it fails with a 409'). An agent knows both when to reach for this tool and when it will fail.

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