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

Annotations say readOnlyHint=false, destructiveHint=false, openWorldHint=true, and the description explains why a nominally diagnostic tool is not read-only: a human ticket can be created, but only with both request_human=true and confirm_escalation=true after explicit user confirmation. It also discloses the required auth scopes, which annotations cannot express. Missing only rate limits, cost, and whether the ticket creation 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?

Three dense sentences, front-loaded with the core action before prerequisites and escalation rules, with no filler. Slight redundancy between 'for the caller workspace' and the workspace_id parameter description, but nothing wasteful enough to cut.

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 auth and the escalation safety gate well for an 8-parameter tool, but with no output schema the description never indicates what comes back (an answer plus diagnostics? a conversation handle?) or how conversation_id/workspace_id defaults interact. An agent knows the guardrails but not the shape of the result.

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 88%, so the schema already documents nearly every parameter, and the description adds mainly the two-flag escalation protocol that the schema fields also describe. It does not clarify the relationship between post_id and referenced_post_ids, or what conversation_id continuation changes about behavior, so it adds little beyond structured fields.

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

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

States a specific verb and resource ('Ask posterly Support AI an authenticated question') and names the ingredients used ('posterly docs plus read-only account/post diagnostics for the caller workspace'). That is distinguishable from sibling feedback/status tools like submit_agent_feedback or posterly_status 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 prerequisite conditions (POSTERLY_API_KEY with accounts:read and posts:read) and the escalation gate (request_human + confirm_escalation after explicit user confirmation), which is genuine when-to guidance. It never says when to prefer this over submit_agent_feedback, submit_product_feedback, or posterly_status, so sibling routing is left 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 already declare readOnly, idempotent, openWorld, and non-destructive behavior, so the safety profile is covered. The description adds meaningful context beyond that: it discloses the return structure and specific scoring rules (missing service areas or an area over 80 straight-line miles caps the score). It does not cover auth/permission needs or rate limits, so 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 sentences, front-loaded with the action and then the return payload; the section list is long but informative and the scoring caveat is placed last. Minor verbosity in the parenthetical section enumeration, but nothing is wasted.

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

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

With no output schema, the description does a good job explaining return values and scoring rules. However, the schema marks zero required parameters, and the description never clarifies that a location identifier (account_id or location_id) is needed to target the audit, leaving an ambiguity for a zero-required-arg 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 coverage is 100% and the schema descriptions already distinguish account_id, location_id, and workspace_id in detail, including the warning not to use the ChIJ Place ID. The description adds no parameter-level meaning, 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: 'Run a live local-profile audit for a connected Google Business Profile location,' and enumerates what it returns (score, grade, section scores, recommendations). It is clearly distinct from list_/manage_ siblings by being an audit rather than a CRUD operation, though no sibling is named explicitly.

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

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

The audit framing implies when it is useful (checking profile completeness), but there is no explicit when-to-use/when-not guidance, no prerequisites, and no reference to the manage_google_business_location or list_google_business_locations alternatives.

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

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

Goes well past the annotations: it declares the billing:write scope requirement, the default period-end scheduling for active and trialing plans, and the important exception that past_due and unpaid plans end immediately regardless of the immediate flag, dropping the unpaid renewal and stopping payment retries. The destructiveHint annotation is reinforced with a concrete confirmation gate rather than merely restated.

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 operation, then the destructive/permission warning, then the behavioral rules. Every sentence carries information, though the past_due paragraph is dense enough that it could be split for scanning; no filler is present.

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 four-parameter destructive mutation with no output schema, the description covers safety gating, permission scope, timing behavior, and the plan-status exception. The only gap is what the call returns (e.g., effective cancellation date), which an agent would have to infer.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: reason must be sourced from the user, immediate=true is conditional on explicit user intent, and immediate is silently ignored for past_due/unpaid plans. It does not mention feedback, leaving that to the schema, which is acceptable.

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 scoped precisely to 'the authenticated user's posterly subscription', which separates it cleanly from pause_subscription, resume_subscription, and downgrade_subscription in the sibling list. 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 ('ALWAYS ask the user why they are cancelling FIRST', 'Only call after the user explicitly confirms') and a precise rule for the immediate flag ('only when the user explicitly wants an active plan cancelled right now'). It also implies the alternative paths (pause/downgrade) by constraining when cancellation is warranted.

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=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), yet the description adds real context beyond them: credentials transit the conversation and the user should be warned, scoped secrets are preferred, and connect_session_id optionally marks connected/failed based on outcome. It does not say what happens on partial success or how errors are surfaced, which keeps it just short of the top.

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

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

The core action and scope lead, followed by prerequisite, credential preference, security warning, and the OAuth escape hatch. Every sentence carries decision-relevant information; nothing is redundant with 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?

For a 14-parameter credential tool with no output schema, the description covers what is needed: which platforms, how to determine required fields, which credential type to prefer, the user-facing security warning, and the sibling to use for OAuth. Return-value explanation is not required given 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 coverage is 100%, so per-parameter meaning is already documented, making 3 the baseline. The description adds value above that by telling the agent how to discover which credential fields a given platform needs (list_platforms with view=connect_link) and by signaling the per-platform credential taxonomy rather than a flat bag of 14 params.

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 (connect a credential-based social account) and immediately delimits the scope: credential-based platforms enumerated inline, and 'without a browser session' rules out the OAuth path. An agent can distinguish this from create_connect_session 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?

Gives explicit when-to-use (credential platforms listed), an explicit when-not plus the alternative (OAuth platforms Instagram/X/LinkedIn -> create_connect_session), and a mandatory prerequisite step (call list_platforms with view=connect_link first). It even ranks credential types, preferring scoped secrets over primary passwords.

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

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

Annotations already establish write/non-read-only, non-destructive, non-idempotent, closed-world, so the description is not obligated to restate them. It adds genuinely non-derivable behavior: the call mints a secret requiring confirmation, scopes are capped by the calling key's scopes, and team-management/portal permissions are deliberately never inherited and must be enabled in /dashboard/api. The one omission is what the response returns (i.e., that the secret itself is surfaced once).

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 purpose then the safety gate in caps, followed by tight constraint sentences. No filler, and the ordering mirrors the agent's decision path (what it does, whether to call it, what it will and won't grant).

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?

Five fully documented parameters and no output schema mean the definition need only cover intent, safety gating, and scope constraints, all of which are present. Nothing an agent needs to decide whether and how to invoke it 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 would be 3, but the description adds real meaning beyond the schema: the inheritance rule for 'scopes' relative to the calling dashboard key and the explicit carve-out that members:read/members:write and client-portal sign-in-link permissions are never copied or granted through this tool. Those are semantic constraints an agent could not infer from the field descriptions alone.

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

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

Names a specific verb and resource ('Create a new posterly API key') plus the actor scope ('for the authenticated user'), which cleanly separates it from sibling delete_api_key and the dashboard/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?

Explicitly gates usage ('only use after explicit user confirmation') and names when it cannot be used ('OAuth and managed assistant tokens cannot mint keys'), which covers the critical alternatives. It stops short of naming a sibling alternative for the excluded permission cases, instead pointing to the dashboard UI.

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 openWorldHint, non-idempotent, non-destructive. The description adds real context beyond them: the session is short-lived, the URL is secure and meant to be handed to the user, and the browser/OAuth steps happen outside the agent. It does not state how long the session lives or that repeat calls mint new sessions.

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 what the tool produces, then the follow-up action, then the guardrail. No filler or repetition of schema text.

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

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

With no output schema, the description still tells the agent that a connection URL is the payload to relay and how to track progress afterwards — enough to call it correctly. Missing only edge-case detail such as what to do if the session expires or the user never opens the URL.

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 platform/auto_start/workspace_id/debug are already documented; baseline 3 applies. The description adds only indirect meaning ('a social account' implies platform) and never touches auto_start, workspace_id, or debug.

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

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

States a specific verb and resource — 'Create a short-lived posterly dashboard handoff session for connecting a social account' — and the scope (per-account handoff, short-lived) separates it from siblings like connect_account and get_signup_session without opening a schema.

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

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

Gives an explicit follow-up workflow ('send the URL to the user, then poll list_accounts with view=connect_session to narrate progress') and a clear prohibition against asking for passwords/OAuth codes. It stops short of naming when a caller should prefer connect_account or get_signup_session instead.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, and non-idempotent, so the description need not re-state that this is a write. It adds real context instead: no dashboard login required for the uploader, a 20-file link cap, an explicit accepted-format whitelist with the HEIC exclusion, and a 50MB size ceiling. It stops short of saying whether drops expire or can be reused, which would complete the picture.

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

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

The purpose and the return value are front-loaded in the first sentence, and the workflow instruction follows immediately. The middle sentences are dense but each carries a real constraint; only the trailing sibling exclusions feel slightly tacked-on rather than integrated into the flow.

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 explaining the return value and does so concretely (drop_url with its URL shape), plus the follow-up call needed after the user uploads. For a mutation tool with three optional parameters, that covers everything an agent needs to call it and act on the result.

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, and the description adds no new meaning about filename, max_files, or workspace_id. The format and size limits it does supply are tool-level constraints rather than 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?

The description names a specific verb and resource ('Create a human drop page') and defines its scope precisely: an upload link for external users, up to 20 files, no dashboard login. It explicitly separates itself from two siblings by name ('not the chat paperclip and not create_signed_upload'), so an agent can pick it out 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 gives the full operating sequence -- create the drop, send drop_url to the user, wait, then call list_media -- which is the when-to-use guidance an agent actually needs. It also states the negative case by naming the two alternatives it is not, so routing decisions are fully determined.

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

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

The description is unusually rich about consequences: public posting is irreversible after scheduled_at, third-party media URLs are copied into posterly storage, signed URLs must be live at call time, X thread character caps, and Article restrictions. However, it labels itself 'This is a DESTRUCTIVE WRITE' while annotations declare destructiveHint=false, a direct conflict in the safety signal an agent uses to decide how much caution to apply. The contradiction is the reason this dimension is scored low despite the otherwise strong 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?

Front-loaded correctly: the irreversible-write warning and the confirmation workflow come first, where an agent will actually read them. The PLATFORM SETTINGS paragraph is a long, comma-spliced enumeration of many platforms that is harder to scan than the rest, but each block is labeled and no sentence is pure 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 13-parameter tool with deeply nested platform objects and no output schema, the description covers what is needed: identification of the account, scheduling semantics, media handling, threads, Articles, and even post-call behavior (report the dashboard link, do not narrate raw HTTP). Nothing essential to a correct first 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 already 100%, yet the description still adds cross-parameter semantics the schema cannot express: account_id OR username+platform as alternative identification, workspace_id fallback order (account's workspace, then caller's default), scheduled_at omission meaning immediate publish, caption being ignored when thread_posts is set, and per-platform constraints on platform_settings and instagram_settings.

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

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

Opens with a specific verb pair and resource: 'Schedule or immediately publish a social media post.' An agent immediately knows this is the single-post creation tool and can distinguish it from create_posts_batch (explicitly named later), validate_post, and update_post.

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

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

Gives an explicit pre-call sequence (whoami, preview, explicit confirmation, then batch preference) and names alternatives: use create_posts_batch for multiple posts in one turn, upload_media first to reuse a posterly URL, and list_platforms with view:'schema' before platform_settings. It also states a negative rule — do not infer consent from earlier standing instructions.

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

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

The content itself is unusually rich beyond the annotations: irreversible public posting after scheduled_at passes, partial-batch success with failed items returned by index, and a required confirm flag. However, it labels itself a "DESTRUCTIVE WRITE" while the annotations declare destructiveHint=false, a direct inconsistency that forces the agent to choose between structured metadata and prose; the disclosure is the safer of the two, so this is not a full-severity contradiction, but it is a real mismatch.

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

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

Front-loaded with purpose and the destructive warning, then organized under REQUIRED BEFORE CALLING and AFTER CALLING headers. Every sentence carries operational weight; nothing is repeated from the schema.

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

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

For a high-blast-radius batch mutation with no output schema, the description covers the safety preconditions, the irreversibility window, the partial-failure return shape, and what the agent should report back including the dashboard link. An agent has enough to call this correctly and safely.

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 cross-reference meaning the schema cannot express: each array item accepts the same fields as create_post, including thread_posts, platform_settings, instagram_settings, media URLs, and workspace_id. It does not explain the confirm semantics beyond the schema's own const/description, which keeps it from a 5.

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

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

Opens with a specific verb, resource, and scope: "Create 1-25 scheduled or immediate social posts in one API request." That immediately separates it from the single-post sibling create_post and from validate_post, and the batching limit is stated up front.

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

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

Gives explicit when-to-use sequencing: call whoami first, preview every post with named fields (account/platform, caption, timezone, media, settings, workspace), then obtain explicit confirmation and never infer consent from an earlier plan. It also names the post-call behavior and points at create_post as the per-item field reference.

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, openWorldHint=true, idempotentHint=false), the description discloses the real behavioral contract: PUT raw bytes to upload_url with the returned headers, 15-minute slot expiry, 403 on Content-Type mismatch under pinning, per-file in-place failure reporting, HEIC rejection, and the 50MB ceiling. These are exactly the operational facts an agent cannot derive 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?

Purpose, limits and formats are front-loaded, and the dense paragraph is almost entirely load-bearing operational detail. Minor waste exists — the pin_content_type 403 behavior appears both in the description and in the schema parameter text — and the block would scan better as short sentences or lines.

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

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

For a 6-parameter tool with no output schema, the description supplies the full round trip: accepted formats, size cap, slot semantics, the PUT step with headers, expiry window, and how the resulting public_url feeds create_post for both regular media and LinkedIn documents. Nothing essential to a correct first 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 baseline is 3; the description still adds meaning by framing filename/content_type/size and files as mutually exclusive modes ("omit when using files" / "use instead of") and by explaining that the files array yields one slot per entry with failures reported in place. It restates the pin_content_type 403 rule already in the schema, which caps it below 5.

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

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

The description opens with a specific verb+resource ("Create signed upload URLs") and immediately scopes it by asset class ("larger images, videos or PDFs") and batch size. It also names the downstream consumers (create_post / create_posts_batch), so an agent can place the tool in the workflow without opening the schema.

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

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

It clearly states the two calling modes (single-file fields vs. files array) and the post-call next step, including the PDF-specific path (post_type document). It does not explicitly compare against sibling media tools like upload_media or create_media_drop, so the agent must infer why this exists beyond "larger" files — that keeps it short of a 5.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds real context beyond them: outbound side effects to an external endpoint, a required user-confirmation gate, and the fact that the signing secret is returned only once in the response. It stops short of describing delivery retry behavior or whether an inactive webhook still counts as created.

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: purpose, safety protocol, and return-value caveat. The safety-critical confirmation instruction is placed prominently before any other detail.

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 six-parameter mutation with no output schema, the description covers the essential risks and notes that the signing secret appears once in the response. Minor gaps remain around default event behavior and what the response contains besides the secret, but the agent has enough to call it safely.

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 83%, so the schema already documents url, events defaults, is_active default, workspace_id scoping, and the confirm const. The description reinforces the significance of url/workspace/events/is_active and the confirmation meaning of confirm, but adds little syntax or constraint detail the schema lacks.

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?

Uses a specific verb+resource ('Create a webhook subscription') and scopes it to post/account/analytics events, so the agent knows exactly what is produced. It does not explicitly name siblings like manage_webhook or list_webhooks, so the create-vs-manage boundary must be inferred from the name alone.

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

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

Gives clear operational context: display target URL, workspace, events, and active state, then obtain explicit confirmation before calling. That is strong guidance for the moment of invocation, though it never states when to prefer this over manage_webhook for edits or how it relates to list_webhooks.

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

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

Annotations already mark destructiveHint=true and idempotentHint=true, and the description adds value beyond that: it flags DESTRUCTIVE in-text and lists the three key classes that cannot be revoked (self-authenticating key, OAuth-issued keys, managed assistant keys), which is not derivable from annotations or schema.

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

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

Three sentences, front-loaded with the verb and an uppercase DESTRUCTIVE warning, followed by the procedure and then the exclusion list. Every sentence carries distinct, actionable information.

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

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

For a two-parameter destructive tool with no output schema, the definition supplies everything needed: identity of the resource, safety procedure, failure/exclusion conditions, and confirmation gating. No material gap remains for correct invocation.

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

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

Schema description coverage is 100%, and the schema already explains that key_id is a UUID resource ID rather than a pst_live_ secret and that confirm must be true after explicit consent. The description reinforces the confirmation flow but adds no parameter detail beyond what the schema provides, so the baseline 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 ('Revoke a posterly API key') plus an ownership scope ('owned by the authenticated user'), which cleanly distinguishes it from create_api_key and other account tools. Nothing about the operation is ambiguous.

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

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

Gives an explicit pre-call procedure (call whoami or use a known key ID, show the user the ID/prefix/name, get explicit confirmation), names an alternative tool (whoami), and enumerates exclusion cases. An agent knows both when to call it 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.

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds material behavior beyond them: irreversibility of posts and captions, the rule that a currently-publishing post is never deleted, that live takedown needs delete_mode=platform plus confirm_published=true, and that refusals keep the record. It also discloses platform authorization requirements (Threads requires threads_delete, YouTube requires youtube.force-ssl, 'upload alone is insufficient'), which is the kind of prerequisite an agent cannot infer from annotations.

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

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

The destructive warning and the two modes are front-loaded, and nearly every sentence carries operational content. It is dense and runs long, with some duplication of the schema's confirm/preview_id wording, but there is no filler prose.

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, multi-mode tool with no output schema, the description covers the preview return value ('call without confirm to get a preview and preview_id'), the confirm loop, platform-specific authorization, and the edge cases (publishing post, published post with no live URL). An agent has everything needed to call it safely.

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

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

Schema coverage is 100%, so baseline is 3; the description goes beyond by explaining that group_id matches a caller-defined group_id, post_group_id, api_group_id, or release_id, and by spelling out the interaction between delete_mode and confirm_published. The only shortfall is that confirm/preview_id behavior is largely restated rather than extended.

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

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

Opens with a specific verb+resource ('Delete posts') and immediately splits the tool into its two operating modes (post_id single delete vs group_id bulk delete), which lets an agent distinguish it from get_post and update_post without opening any schema. Scope limits are stated explicitly, e.g. 'A group delete never removes published posts.'

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 when-to-use procedure: fetch with `get_post` first, show caption/account/scheduled time, and pass confirm=true only after explicit confirmation with example phrases. It also names the preview-then-confirm flow for group deletes and an exclusion ('Never delete several posts one by one without listing each and confirming the full list').

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, but the description goes further by naming the concrete consequences: the connection is removed, account.disconnected webhooks fire, and Instagram scheduled posts may be transferred to a replacement account. That side-effect detail is unavailable anywhere in 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?

Front-loaded with the action and its destructiveness, then a clearly separated REQUIRED BEFORE CALLING block for the precondition. No filler sentences; each clause carries either a side effect or a gating rule.

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, the description covers consequences, the confirmation gate, and the prerequisite discovery call. Nothing an agent needs in order to invoke this safely 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 both parameters are self-documenting, so the baseline is 3. The description adds a small amount by tying confirm to a specific gating workflow ('only after that confirmation') and anchoring account_id to list_accounts, though it largely restates the schema text.

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 ('Disconnect a connected social account from posterly') and is clearly the inverse of the sibling connect_account. An agent can distinguish it from account-adjacent tools like manage_extra_account or list_accounts without opening a schema.

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

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

Gives an explicit precondition sequence: call list_accounts first, surface platform/username/account ID/workspace, obtain explicit user confirmation, then pass confirm=true. This is a when-and-how-to-use rule with no inference required, and the implicit alternative (connect_account) is obvious from the naming.

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

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

Annotations already flag destructiveHint and idempotentHint, but the description adds real context beyond them: a draft is not scheduled and nothing is published, and already-converted suggestions are protected from dismissal or overwrite. It still says nothing about the effect on the originating suggestion record or whether a dismissal can be undone.

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

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

Front-loaded with the primary action and its alternative, then the safety requirement. The final sentence ('Never dismisses, and does not overwrite, a suggestion that was already turned into a post') is slightly convoluted and could be tighter, but every sentence carries information.

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

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

For a two-parameter mutation with no output schema, the description covers both modes, the confirmation requirement, and the protected-record case. Only the result of a successful call (what the agent sees back) is left implicit.

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

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

Schema coverage is 100%, so the 3 baseline applies, and the description does earn more by explaining the consequence of save_as_draft (unpublished, not scheduled, nothing published) rather than just restating that it saves a draft. suggestion_id is left to the schema, which already points to list_post_suggestions.

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 (dismiss) and resource (a proactive post suggestion) plus a second explicit mode (save_as_draft converts it to an unpublished draft). The dual behavior is unambiguous and clearly distinct from the listing sibling referenced via suggestion_id.

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 condition for both modes and a hard prerequisite ('WRITE: confirm the exact suggestion with the user first'), plus an exclusion for suggestions already converted to a post. It does not name an alternative tool for handling suggestions (e.g. list_post_suggestions), so it falls short of a 5.

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

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

The description adds substantial behavior beyond the annotations: lower limits and credits apply immediately, the lower price starts at the next renewal, and the current period is not refunded. This is exactly the kind of consequence an agent needs before invoking a destructive billing 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?

The description is dense but front-loaded, with the core action first and timing, refund, permission, and confirmation constraints following. Every clause carries operational meaning for a destructive billing action.

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

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

For a destructive subscription mutation with no output schema, the description covers timing effects, refund behavior, directionality, permission requirements, and confirmation requirements. Nothing essential for safe invocation 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 description coverage is 100%, so both the optional target tier and required confirmation are already documented in the schema. The description reinforces that the target must be lower and that confirmation is explicit, but adds no syntax or format details beyond the schema.

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

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

The description states a specific verb and resource: downgrade the subscription one tier or to an explicit lower tier. It clearly distinguishes this from upward, cancellation, pause, and resume operations through 'strictly downward only.'

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

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

It gives strong usage constraints: downward moves only, requires billing:write, and must be called only after explicit user confirmation. It does not explicitly name upgrade_subscription or cancel_subscription as alternatives, but the downward-only scope makes the boundary 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 is a read-only, idempotent, non-destructive operation. The description adds substantial behavior beyond that: a one-hour gap between posts, preferred posting hours of 8am–10pm, a cap of 10 slots, the default timezone pitfall, the UTC instant returned for scheduled_at, and the ranking behavior of best_engagement with star ratings and reasons.

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

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

The description is front-loaded with purpose and packs important constraints into a single dense paragraph. It is efficient, though the density makes it slightly harder to scan than an ideally structured definition.

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

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

With five optional parameters, no output schema, and annotations covering safety, the description supplies the missing operational context: return format, timezone risk, strategy requirements, and scoping behavior. An agent has enough information to call the tool correctly without further inference.

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

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

Schema coverage is 100%, so the schema already documents all five parameters, making 3 the baseline. The description still adds meaning by explaining cross-parameter dependencies (best_engagement requires account_ids) and the differing default counts between strategies, which the schema only partially conveys.

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 opens with a specific verb and resource: "Find available time slots for posting." It immediately distinguishes itself from post-creation siblings like create_post and scheduling tools by focusing on slot discovery, and it names the two strategies so an agent can tell what kind of result to expect.

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

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

It gives clear usage conditions: pass timezone explicitly, use workspace_id to scope collision avoidance, and use best_engagement only with account_ids. It does not explicitly name alternative tools or state when not to use this tool, but the context is otherwise 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 flag readOnlyHint=false and openWorldHint=true, and the description adds the critical non-obvious context that calls consume AI Caption Assist quota and produce suggestions only. It does not say whether quota is charged per call or per platform, nor whether repeated calls re-consume quota (relevant given idempotentHint=false), 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?

Three tightly written sentences with zero filler. The capability statement comes first, followed by cost/output behavior and then the handoff instruction, which is the right order of priority.

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 15-parameter tool with a nested brand-voice object and no output schema, the description covers purpose, cost, and handoff well but leaves the caller without any sense of the returned suggestion shape or how mode=adapt differs operationally. It is adequate for routing, not for confident invocation.

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

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

With 15 parameters and only 33% schema description coverage, the description needs to carry most of the semantic load, but it only weakly implies multi-platform input ("one or more social platforms"). It explains nothing about mode, tone, hashtag_strategy, brand voice, or the preservation flags, so the majority of undocumented parameters remain unguided.

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 opens with a specific verb and resource: "Generate or adapt AI caption suggestions for one or more social platforms." It distinguishes the two modes (generate/adapt) and explicitly separates itself from post creation, so an agent can tell it apart from create_post or generate_image without opening a schema.

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

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

It states both the when-not ("returns options only; it does not create or schedule posts") and the follow-up alternative ("pass it to create_post or create_posts_batch"). This gives an agent a complete workflow boundary rather than leaving sequencing to inference.

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

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

Annotations only flag non-readonly, open-world, non-idempotent. The description adds the critical behavior annotations don't cover: every call consumes quota/credits, variations cost separately, a 402 means over-limit with no retry, and the message should be surfaced verbatim. That is exactly the context an agent needs before a paid, non-idempotent 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?

Front-loads purpose, job flow, and cost warning before the bulleted aspect-ratio reference, so the important parts are not buried. The platform bullet list is somewhat long but each line maps a real decision to a concrete ratio, so it 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 12-parameter, asynchronous, credit-consuming generation tool with no output schema, the description covers the full lifecycle (queue, poll, hand off), the cost/confirmation gate, and the over-limit failure mode. Nothing an agent needs to invoke it safely 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 field descriptions are already detailed (credit tiers per model/resolution, thinking_level precedence over quality, xAI constraints). The description still adds value by supplying the platform-to-aspect-ratio mapping that the aspect_ratio field explicitly defers to ('see tool description').

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

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

States a specific verb and resource ('Queue an AI image job') plus the underlying providers (Nano Banana/Gemini, Grok Imagine/xAI), and immediately declares the return value (job_id). This clearly separates it from the nearby generate_video and upload_media siblings.

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

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

Gives an explicit end-to-end workflow: call this, poll list_jobs with type=image, then feed urls into create_post as media_url/media_urls. It also names a when-not-to-call rule ('Do NOT call speculatively') and the confirmation prerequisite.

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 it discloses the credit cost, the mandatory user-confirmation gate, provider-specific constraints (Grok 1-15s and 480p-1080p, reference-to-video capped at 720p), and that the call is asynchronous and must be polled via list_jobs for the final video_url. That is a lot of behavior an agent could not infer from readOnlyHint=false / openWorldHint=true alone.

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: purpose, the credit/confirmation warning in caps, then provider constraints and the polling instruction. Front-loaded with the highest-risk information (it costs money) and no filler.

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

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

For a 14-parameter, non-idempotent, open-world mutation with no output schema, it covers the decision-critical pieces: cost, confirmation, provider limits, and how to retrieve results. Gaps remain around the model tier enum and the image/end-image/source-video input modes, which an agent would have to guess from the schema alone.

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

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

Schema description coverage is only 21% across 14 parameters, so the description carries a heavy burden. It adds meaning for provider, duration, resolution, audio, and reference-image limits, but says nothing about model (lite/fast/standard), workspace_id, negative_prompt, image_url, end_image_url, or source_video_url, leaving roughly half the surface undocumented anywhere.

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?

"Queue an AI video generation job with Google Veo 3.1 or xAI Grok Imagine Video 1.5" names a specific verb, resource, and the two backing models, which separates it cleanly from generate_image and get_video_options in the sibling list.

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

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

It gives an explicit precondition (confirm provider, prompt, duration, resolution, aspect ratio, audio, and credit cost with the user before calling) and names list_jobs with type=video as the follow-up step. It does not contrast itself with siblings like run_video_function or get_video_options, so routing between video tools is left partly 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, non-destructive and closed-world, so safety is covered structurally. The description adds genuinely new context: this is an instructional tool and it covers 'safe human-in-the-browser boundaries', which tells the agent a human must act in a browser at some steps. It does not say what form the explanation comes back in (text vs. structured steps), a minor gap for a no-output-schema tool.

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

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

One sentence, front-loaded with the verb and purpose, with the only additional clause ('including the safe human-in-the-browser boundaries') earning its place by flagging the human-interaction constraint.

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

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

For a zero-parameter, read-only informational tool with no output schema, the description says enough to call it correctly and to know why. What remains missing is the expected return shape and the handoff to the actual signup/API-key tools, which would help an agent chain the 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 the schema is empty, so there is no parameter meaning for the description to supply. Baseline 4 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 ('Explain') and resource (agent-led signup workflow via posterly MCP before an API key exists), which clearly separates it from action siblings like start_signup, get_signup_session or create_api_key. It stops short of naming those siblings, so differentiation is implied rather than explicit.

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

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

The phrase 'before an API key exists' gives a concrete precondition that tells the agent when this tool applies rather than the signup/API-key tools. It does not name the follow-up tools (start_signup, create_api_key) an agent should call afterwards, so the routing guidance is incomplete but still clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered structurally. The description adds genuinely new context: the required billing:read scope and the fact that credits are a shared workspace wallet, which changes how the returned figure should be interpreted.

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

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

Two dense sentences with the core answer front-loaded and no filler. Every clause carries information the agent needs: balance components, wallet semantics, cost, and auth scope.

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 parameters, no output schema, and annotations covering safety, the description is close to complete—it even enumerates the balance fields an agent will receive. It stops short of describing the response shape or formatting, which is the one gap given the absence of an output schema.

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

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

The tool takes zero parameters, so there are no parameter semantics to document and the schema coverage question is moot. Baseline 4 applies; no meaning is added or needed beyond the empty object.

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

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

States a specific verb and resource ('Get the authenticated user's posterly AI credit balance') and then enumerates exactly what the balance comprises: available spend, remaining monthly allowance, purchased pack balance, plan tier, and reset timing. An agent can distinguish this from subscription-management siblings like get_subscription purely from the text.

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

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

Gives clear context for when this is the right call (read-only, spends nothing, requires billing:read scope) and clarifies the shared-workspace semantics so callers don't mistake it for a personal balance. It stops short of naming an alternative sibling or explicitly stating 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 cover read-only, idempotent, non-destructive, and closed-world behavior, so the description adds the return-shape detail: fields for the post view, failure reason on failed publishes, and per-field remediation for the missing view. It does not address how a nonexistent post ID is handled.

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

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

The core statement is front-loaded in the first four words, and the remaining field lists are informative rather than filler. The two sentences are long but each clause carries concrete content about the returned data.

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 takes on the burden of describing return values across both views, which it does thoroughly. Minor gaps remain: no mention of error behavior for invalid IDs and no note on whether the response nests objects.

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

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

Schema coverage is 100%, but the schema only says "post (default) or missing" while the description explains in detail what each view returns and what the missing view is for. That adds real semantic meaning beyond the enum definition.

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?

"One post by ID" gives a specific verb (retrieve) and resource (post), and the two view modes are enumerated precisely. It does not explicitly name siblings like list_posts or update_post, so differentiation is implied by "one" rather than stated.

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

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

The description implies usage for view=missing ("how to fix it before the post can publish") which tells an agent when troubleshooting is relevant. However, there is no explicit guidance on when to choose get_post over list_posts or update_post, and no stated prerequisites or exclusions.

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

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

Annotations already cover read-only, idempotent, non-destructive, open-world semantics, but the description adds real behavior: this is a polling call on a public session, it exposes billing nuance (card saved, nothing charged today, prior-trial accounts charged at checkout), and it constrains how results should be surfaced to users. Return shape is still not described, keeping it below a 5.

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

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

Three compact sentences, front-loaded with the core action and followed by usage and narration constraints. The final sentence about not narrating curl/HTTP plumbing is slightly tangential to invocation but earns its place as a behavioral constraint.

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-only polling tool with no output schema and fully covered parameters, the description supplies enough: what it polls, the states it surfaces (trial, password setup, agent access), and the billing edge case. Nothing needed to call it 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 session_id's origin (returned by start_signup, usually the Stripe checkout session ID) and the debug flag are already documented in the schema. The description only loosely reinforces the session_id provenance and adds no format or usage detail beyond it, 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 and resource ('Poll a public posterly signup session') and ties it to the originating sibling ('created by start_signup'), so the agent can distinguish it from start_signup or get_agent_signup_info without opening a schema.

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

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

Gives a clear use context — narrating trial, password setup, and agent access status before an API key exists — plus the edge case that an account with a prior trial is charged at checkout. It does not explicitly rule out or name alternatives such as get_agent_signup_info, so it falls short of a full when/when-not statement.

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 destructiveHint=false, so safety is covered structurally; the description adds value by stating the 'billing:read' scope requirement and by disclosing that the response includes upgrade paths, Agency extra-account state and next steps. It stops short of noting any rate limits or failure modes, so it earns 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?

Well front-loaded: what it returns comes first, then when to call it, then constraints. The middle sentence is dense and slightly overloaded with parentheticals ('plan tier plus any extra slots'), but every clause carries real information rather than restating the name.

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 does the work of describing the payload contents and even hints at actionable next steps. Only the shape of 'the exact next steps' and the ordering of the plans list remain unspecified, which is a minor gap for an otherwise thorough definition.

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

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

There are zero input parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description instead spends its words on output semantics, which the schema cannot carry.

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

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

Names a specific verb and resource (get the caller's subscription) and then enumerates the exact fields returned: status, tier, cancel-at-period-end, period end, trial end, pause state, connected accounts and account limit. It also separates itself from upgrade_subscription / cancel_subscription by being explicitly the read-only status entry point.

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

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

Gives explicit when-to-use triggers in the user's own words ('upgrade', 'change plan', 'add accounts', 'how many accounts') and an ordering directive: 'Call this FIRST'. That is precisely the routing information an agent needs when several subscription siblings exist.

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 readOnly, idempotent and non-destructive, so the safety profile is settled. The description adds two genuinely useful behaviors: that the response indicates whether more updates exist (a pagination signal with no output schema to reveal it) and that an active posterly subscription is a prerequisite. Return shape beyond that continuation flag is left implicit.

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 purpose then pagination strategy, with zero filler. The subscription prerequisite is placed last where it reads as a constraint rather than a preamble.

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 four-optional-parameter read tool with no output schema, the description covers purpose, ordering, pagination mechanics and a prerequisite. The one real gap is that entry-level fields (e.g. what an update looks like, title/date/category) are not characterized, though 'include_content' in the schema implies a body field.

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

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

Schema coverage is 100%, so baseline is 3, but the description earns a modest bump by explaining how 'offset' and 'since' are functionally used (page vs. narrow) rather than just naming them, which the schema text only partially duplicates. It says nothing extra about 'limit' or 'include_content', which the schema already documents fully.

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

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

States a specific verb and resource ('Get the latest posterly product updates and news from the updates feed'), enumerates what is returned (new features, improvements, fixes), and specifies ordering ('newest first'). No sibling tool covers product updates, so no disambiguation is needed and an agent can identify the tool immediately.

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 conditional guidance for the two discovery strategies: page with 'offset' for the next page, or narrow with 'since' for a date cut. It stops short of explicit when-not-to-use guidance or naming alternatives, but for a feed-reading tool the usage context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so safety is covered structurally. The description still adds non-redundant information: that no credits are spent, which is a cost behavior the annotations cannot express and which matters in a credit-metered product. It does not describe whether the returned options are account- or plan-specific, which would have been the final piece.

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: the first front-loads what is returned, the second front-loads the negative guarantee (no generation, no credit spend). Every clause earns its place and the most decision-relevant fact for an agent is stated first.

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 parameters, no output schema, and rich annotations, the description carries exactly the remaining burden: it enumerates what the response will contain so the agent can judge relevance without a return schema. For a simple read-only discovery tool, nothing an agent needs before calling it is absent.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond what the empty object schema already shows; the baseline for a parameterless tool applies. No parameter meaning is missing or misleading.

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?

Uses a specific verb ("List") plus a precise resource ("read-only Veo video generation options") and enumerates the exact contents: input modes, durations, resolutions, aspect ratios, credit-cost estimates. It also explicitly negates the closest sibling behavior ("does not generate video"), so an agent can distinguish it from generate_video and run_video_function 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?

The closing sentence clearly signals this is a discovery/metadata call rather than a generation call, implicitly routing video creation to generate_video. It stops short of stating the explicit trigger (e.g. "call this before generate_video to pick a valid mode/duration/resolution"), so the when-to-use is clear but not fully 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 declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds value by enumerating the returned fields in the absence of an output schema, but says nothing about quota reset timing, units, or whether 'managed' quota derives from the addon.

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 front-loaded sentence with no wasted words; the resource is stated before the field enumeration. Slightly dense as a single list, but every element 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-optional-param read tool this is largely sufficient, and the return-field enumeration compensates for the missing output schema. However, undefined terms ('managed', 'URL-blocking status') and the absence of reset cadence leave an agent guessing about what the values mean.

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 workspace_id is fully documented, including its default to the caller's personal workspace. The description's 'for a workspace' adds no syntax or behavior beyond the schema, so the baseline 3 applies.

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

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

States a specific verb ('Get') and a well-scoped resource ('managed X posting quota for a workspace'), then enumerates the returned components (monthly allowance, used, remaining, URL-blocking status). An agent can distinguish it from get_credits or get_subscription by the X-posting-specific scope, though no sibling is named explicitly.

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

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

There is no guidance on when to call this versus checking plan limits via get_subscription or adjusting quota via manage_x_posting_addon. The description also omits any precondition such as resolving workspace_id from whoami first.

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, but the description adds non-obvious behavior: tokens are never returned, learned_voice never overwrites the saved brand profile, performance_profile requires Pro or higher and is absent for platforms without per-post analytics, and connect sessions must be polled with a plain-language update. Those 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-loaded with the resource definition, then ordered by view, with no filler sentences. It is dense and semicolon-heavy, and the long first sentence compresses two ideas, but every clause carries operational 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 six-parameter, four-mode dispatcher with no output schema, the description covers mode selection, return contents at a high level, plan gating, and polling termination. It stops short of describing pagination or the full row shape beyond connection_status, which is the only remaining gap.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds a constraint the schema does not state: view=accounts accepts one workspace_id or one account_id, implying mutual exclusivity. It also ties each parameter to its view, though per-parameter detail largely duplicates the schema.

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

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

The first sentence states the resource and its scope (connected social accounts plus learned data), and the four views are each given a distinct verb-like definition. An agent can distinguish this from connect_account, disconnect_account, and create_connect_session 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?

Explicit routing is given per view, including that view=accounts is the default, that connection=needs_reconnect is the way to narrow to broken accounts, and that connect_session should be polled until status is connected, failed, cancelled, or expired. It also names a prerequisite check (inspect Instagram rows before using user_tags or collaborators), which is exactly the when-to-use guidance a sibling-heavy tool needs.

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

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

Annotations already establish this as a safe, idempotent read in a closed world, so the description adds value with ordering ('newest first'), the paging window ceiling (offset + limit up to 1000), and the fact that the response signals whether more events exist. That last point is real behavioral disclosure beyond the annotations, though it stops short of describing result shape or defaults in detail.

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

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

Three sentences, front-loaded with purpose then usage then paging caveat. No filler, and the most important operational warning (don't conclude nothing happened) lands last where it is memorable.

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 compensates by stating that the response indicates whether more events exist. All six parameters are documented in the schema and the description covers the pagination model, so 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%, so the baseline is 3, but the description adds genuine meaning: it explains the combined offset+limit ceiling of 1000 (a constraint not expressed in the schema, which only caps limit at 100), and frames offset/since/post_id as paging and narrowing levers for this feed.

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 opens with a specific verb and resource ('List recent activity and publish events for posts') and enumerates the event kinds covered (status changes, publish attempts, failures, retries). This clearly separates it from siblings like list_posts or list_jobs, which deal with content rather than event streams.

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 usage context ('Use this as the agent notifications feed') and prescriptive guidance on pagination and narrowing before concluding there is no more data. It does not name a sibling alternative or state when NOT to use it, which keeps it short of a 5.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds real behavior beyond them: posts are returned 'most recent first', insights are read-only and plan-gated, and include_extras data 'stays off until snapshot extras are switched on, and this does not start a new sync'. Those last points are the kind of side-effect clarity annotations cannot express. It omits failure behavior for invalid accounts or empty date ranges.

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

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

It is a single dense paragraph where nearly every clause carries information (view semantics, platform exception, plan gate, presentation mapping). It would scan faster with the three view modes split into distinct sentences or lines, and the long platform enumeration adds little 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 10-parameter, three-mode, no-output-schema tool, the description covers the mode split, platform caveat, pagination ordering, plan gating, presentation formats, and the include_extras sync caveat. The main remaining gap is that date-range defaults and their interaction with view=insights are left entirely to the schema.

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

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

With schema coverage at 100%, baseline is 3; the description earns more by giving presentation values actual meaning ('compact for Telegram/mobile, table for Markdown clients, json for custom chart/card renderers') and by explaining what include_extras surfaces and that it is inert until extras are enabled. Checkpoint values and account-scoping rules are also restated with context, though from/to and limit/offset add nothing beyond the schema.

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

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

The description names the resource (analytics for connected social accounts) and enumerates exactly what each of the three views returns, so an agent can tell this apart from list_posts or list_comments. It never states an explicit action verb such as 'retrieve' or 'list', relying on the surface-noun phrase 'Analytics for...' plus the per-view return lists to imply read retrieval.

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 routes between the three view modes with concrete conditions: per-post data goes to view=posts, while 'Google Business has no per-post rows; its totals are on view=accounts' is an explicit when-not rule. It also gates view=insights behind 'Pro plan or higher'. It does not point to sibling tools for adjacent needs (post content, comments, account discovery beyond the parenthetical 'from list_accounts').

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds genuinely useful behavioral detail beyond that by spelling out the payload of each view, which matters because there is no output schema. Pagination, ordering, and error behavior for an invalid brand_id are not disclosed.

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 front-loaded sentence states the resource, followed by a parallel view-by-view enumeration that is easy to scan and free of filler. It is dense, with four view clauses packed into a single paragraph, but every clause 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?

With no output schema, the description compensates by describing the returned fields for each view, which is the main thing an agent needs to pick a view. Remaining gaps are minor for a read-only listing tool: no note on ordering, volume, or what happens when brand_id is omitted or 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 coverage is 100%, so the baseline is 3, but the description goes further by mapping each parameter to a view (workspace_id only for view=brands, brand_id required for the other three) and by describing what the view parameter actually selects. This gives an agent a working model of the parameter interactions rather than just field-level text.

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 opens with a specific verb-and-resource framing ("Brands (clients) and their saved context") and then enumerates exactly what each of the four views returns. It also implicitly separates itself from list_accounts by noting the accounts view is for when a user names a brand rather than an account handle.

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?

Each view is tied to a clear selection condition (default brands, single brand by brand_id, social accounts by brand_id, saved profile context by brand_id), and the accounts view includes an explicit disambiguation rule versus account handles. It stops short of naming sibling tools like manage_brand or list_accounts as alternatives, so routing to non-listing operations is left to inference.

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

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

Goes well past the readOnly/idempotent annotations by disclosing the permission requirement ('Pro plan or higher plus posts:read') and, importantly, that YouTube and TikTok are hard-refused rather than returning an empty list — an error mode an agent would otherwise misread as 'no data'. It also explains why those platforms are off, so the refusal is understood as intentional.

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

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

Front-loaded with scope and platform list, then the two modes, then the refusal behavior — a logical order with no filler sentences. The closing line about platforms staying off until reviewed is mildly editorial but still conveys why refusals occur.

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 10-parameter, zero-required, read-only tool with no output schema, the description covers mode selection, gating, paging approach, and failure behavior. A brief note on the shape of the paged response (e.g. whether replies are nested) would close the remaining gap.

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

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

Schema coverage is 90%, so the baseline is 3, but the description adds real meaning on top: it clarifies that filter covers 'unread/flagged', that search/account/platform/since-until are list-mode-only, and that comment_id inverts the call into a single-record-plus-replies lookup where only workspace_id is honored. That interaction between parameters is not expressible in the schema.

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

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

Names a specific verb and resource ('list comments') along with the exact platform scope (Instagram, Facebook Pages, Threads, LinkedIn Pages) and splits behavior into two clearly labeled modes keyed on comment_id. An agent knows precisely what this returns versus what it refuses.

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

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

Explicitly states the two calling modes ('Without comment_id: list comments filtered by...' / 'With comment_id: one comment and its replies') and the constraint that only workspace_id may be combined with comment_id, which is real when-to-use guidance. It does not name a sibling alternative (e.g. manage_comment for writes), 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 carry readOnly/idempotent/non-destructive, so the description is free to add genuinely new behaviour: the plan and scope requirement, mode-dependent meaning of limit, default 50/max 100, and the Meta reply-window caveat that a reply does not extend the window and it is not inferred from loaded messages. That last point is real domain behaviour an agent could otherwise get wrong; only return shape is left uncovered.

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

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

Front-loaded and organised around the two modes, with the plan requirement parenthesised rather than buried. Sentences are long and dense, and the trailing reply-window note takes three clauses, but 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 10-parameter read tool with no output schema, the definition covers modes, defaults, mutually exclusive filters, access gating and the reply-window caveat. An agent could invoke it correctly; only the returned conversation/message field structure is unspecified, which is a modest gap given 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 coverage is 100%, so baseline is 3, but the description adds meaning the schema cannot express: limit counts conversations normally and messages when conversation_id is set, and other filters are invalid in single-conversation mode ('only workspace_id may be added'). That cross-parameter constraint is the most useful thing it contributes.

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

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

Opens with a precise verb+resource and scope: 'Social inbox DM conversations for Instagram and Facebook Page inboxes', and immediately kills the obvious confusion by noting Threads has no DMs. The dual-mode behaviour (list vs single-conversation retrieval) is stated up front, so an agent can distinguish this from list_comments or manage_conversation.

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 partitions usage by argument: without conversation_id you list with filters and paging, with conversation_id you fetch one thread and its messages with only workspace_id addable. It also states the access prerequisite (Pro plan or higher plus posts:read). It stops short of naming competing siblings such as manage_conversation or list_comments to route away from.

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 non-obvious behavior by disclosing the feature-flag gate and that no upstream Google call occurs while disabled, which prevents an agent from misreading an empty result as 'no data'. The remaining gap is that it doesn't say what an empty/disabled response looks like.

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 the purpose, then gating, then parameters, then negative scope — no filler. The only cost is a slightly choppy telegraphic style, but every sentence carries information.

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

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

For a read-only three-parameter tool with full schema coverage and no output schema, the description covers purpose, availability gating, parameter choice, and what is excluded from the response. The one unresolved ambiguity is whether the 'one location' framing is triggered by account_id vs location_id and what happens when account_id selects multiple locations.

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 each parameter already carries detailed guidance (including the ChIJ Place ID warning and 'Prefer account_id'), so the schema does the heavy lifting. The description's 'Pass account_id or location_id' only restates the either/or without adding format or precedence detail beyond the schema, so the baseline of 3 applies.

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

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

The description gives a specific verb+resource: 'Read regular opening hours and attributes for one Google Business location,' plus negative scope ('does not return the business name, address, phone, or website'), which meaningfully bounds what an agent gets back. However, the stated single-location scope sits awkwardly against the tool name 'list_google_business_locations' and the sibling 'manage_google_business_location', so an agent must reconcile a list-style name with a read-one-location behavior.

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 a real precondition (only active once 'location edits are switched on,' no Google calls while off) and the 'Pass account_id or location_id' hint, which helps an agent decide whether the call will do anything. It never names alternatives — e.g. when to use list_accounts or manage_google_business_location instead — so the when-not guidance is implied rather than stated.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavior: pagination operates over a gallery already fetched from Google rather than requesting a smaller page upstream, and it enumerates the returned fields (resource name, category, format, image URL, date).

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 and the disambiguation before pagination details. The final sentence largely duplicates what the limit/offset schema descriptions already say, which is the only wasted space.

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

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

With five optional parameters and no output schema, the description compensates by listing the return fields and explaining the paging model. It omits how an agent knows it has reached the last page or what happens when no media exists, which are minor gaps for a read-only listing tool.

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

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

Schema coverage is 100%, so every parameter is already documented, including the limit default/max and the offset semantics. The description restates limit 50/200 and offset skipping without adding syntax or guidance beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('List the photos and videos on a Google Business Profile gallery') and scopes it to Maps/Search. It explicitly separates itself from post-attached media, which is the key ambiguity against the sibling list_media and manage_google_business_media 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?

Clear about the two supported scopes: a single location/account or every accessible GBP location, and it excludes the post-media case. It does not name the sibling tools (list_media, manage_google_business_media) or state when to prefer those, so routing still needs a small inference step.

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, non-destructive, so the description is free to spend its words elsewhere - and it does: it discloses that paging retrieves all reviews rather than the first 50, that review text is untruncated, and that each location's total review count is returned. That is genuinely useful context beyond the annotations, though it does not discuss rate limits or per-call cost of deep paging.

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?

Content is front-loaded with the primary mode and no sentence is filler, but the 'reviews' portion is a single very long clause chain that is harder to parse than it needs to be. Slight tightening would make the paging/filtering facts scannable.

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

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

There is no output schema, so the description carries the return-shape burden and does it: it names the fields an agent will get back (full review text, date, review_name, per-location total count, public link, Place ID). Together with the mode split and the Place ID caveat, an agent has everything needed to call this correctly on the first try.

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 the limit/offset pairing as a paging mechanism and by clarifying the account_id vs location_id relationship (prefer account_id; location_id is numeric, not the ChIJ Place ID). It does not describe the workspace_id filter, which is left entirely to the schema.

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

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

The description names the resource (Google Business Profile reviews) and the two explicit modes (view=reviews vs view=review_link), each with a precise scope. It is clearly distinguishable from the sibling manage_google_business_review, which it references only as the follow-up action for replies/deletes.

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 which view to pick and for what: reviews for listing/filtering/paging, review_link when the public review URL or Place ID is needed. It also gives a concrete routing rule ('Each review has review_name for manage_google_business_review reply/delete_reply') and an explicit prohibition ('that Place ID is output only and must NOT be passed back as location_id'), which prevents a likely misuse.

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 destructiveHint=false, so the description correctly does not spend words on safety. It adds real behavioral context instead: the 20-area cap, the server-side dependency on a maps key, and the warning that Place IDs from view=places are regions rather than the review-link Place ID. It does not describe the shape of the returned area list, which leaves a small gap.

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

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

Front-loaded with the core purpose, then a clear view-by-view breakdown, with no redundant restatement of parameter names. The closing sentence about the maps key and the update fallback is dense and packs two ideas together, but every clause carries information.

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

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

A read-only, six-parameter tool with no output schema, and the description covers both modes, the required-parameter condition, the maps-key prerequisite, and the Place ID pitfall. What remains unstated is the return payload for each view, which is acceptable given the tool's read-only nature but leaves the picture slightly incomplete.

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 a baseline of 3 applies and the description must earn more. It does so by stating the cross-parameter conditional (q required for view=places) and by adding the operational constraint that town search needs a maps key on the server, neither of which is derivable from the schema alone.

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

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

Opens with a specific verb and resource ("Read Google Business service areas") and clarifies the domain object as "the towns and postcodes a location covers, up to 20." This is enough to distinguish it from the sibling mutation tool manage_google_business_service_area 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?

Splits usage cleanly by view: areas (default, one location) versus places (requires q, searches for a town or postcode to add). It also routes the agent away from town search when no maps key is configured, telling it to add a place via the update instead. It stops short of naming the manage_google_business_service_area sibling explicitly.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, so the safety profile is covered; the description adds material context beyond that, such as the video status set including 'dismissed' and the returned fields (urls, video_url). It doesn't cover ordering or pagination of the list results, which would matter for polling loops.

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

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

It is dense and front-loaded, with the type=image branch stated before type=video and the polling purpose repeated per branch. The repetition of 'poll it after generate_*' is mildly redundant but earns its place by tying each type to its generator.

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 names the key return values (finished urls for image, video_url for video), which is what an agent needs after a generate call. It leaves the ordering of 'recent jobs' and whether limit caps the list undefined, a minor gap for a four-parameter read 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 coverage is 75% and the schema already documents type, job_id, and status. The description adds per-type semantics the schema doesn't: that job_id selects a single job of the given type, that omitting it triggers a list, and that status/limit apply to the list form for each type.

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 opens with the resource ('AI generation jobs') and then spells out the two distinct retrieval modes per type: a single job by job_id versus a recent-jobs list when job_id is omitted. It explicitly names the sibling tools (generate_image, generate_video) it pairs with, so an agent can distinguish it from anything else in the catalog.

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

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

It gives clear when-to-use guidance — poll after generate_image for finished urls, poll after generate_video for video_url — and explains the job_id-omitted case as listing recent jobs. It stops short of stating when NOT to use it or naming an alternative tool, so it falls just under a 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavior beyond them: default page sizes, the 20-file drop page, the offset+limit ceiling of 1000, and the fact that the response signals whether all matching files were returned. It stops short of describing error or empty-result behavior, so not a 5.

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

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

Five short sentences with the core purpose front-loaded and no filler. The paging and output-shape details are packed densely but earn their place; the last sentence is slightly overloaded with two ideas (completeness flag plus paging math).

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 covers return contents (filename, added time, completeness indicator) and paging. It leaves implicit whether non-drop media reachable by this tool beyond uploads, and no sort-order detail, but nothing critical to 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 baseline is 3, but the description adds meaning the schema lacks: the offset+limit <= 1000 constraint and the drop-session context for drop_session_id. It doesn't explain limit/offset interaction with sorting exactly, so just above baseline.

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

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

"List the newest media assets for the authenticated user" gives a specific verb, resource and ordering scope, and the second sentence carves out the drop-listing mode so an agent can tell it apart from upload_media / create_media_drop / create_signed_upload.

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

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

It states the chained workflow explicitly ("After create_media_drop, pass drop_session_id to see files the human uploaded on /drop/<token>") and names the downstream consumers ("Use public_url with validate_post / create_post"). It also gives a paging rule of when to page vs not, which removes the main ambiguity an agent would have.

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered by structured data. The description adds real value beyond that by clarifying these are PUBLIC PKCE clients, i.e. no client secrets are exposed, and that results are filtered to the calling user's ownership. It says nothing about pagination, empty results, or whether disabled/deleted clients appear.

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 identity of the resource is front-loaded before the qualifying detail about PKCE clients. Every clause earns its place.

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

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

For a zero-parameter listing tool with no output schema, the description says what is listed but not what a returned record looks like (fields such as client ID, name, creation date, status). That is the main remaining gap for an agent that must decide whether the response contains what it needs.

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 per the baseline this scores 4. There is no parameter meaning the description needs 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?

The description gives a specific verb ("List") and a precisely scoped resource ("self-serve OAuth developer clients owned by the user"), then defines them further as public PKCE clients for third-party integrations. The scope qualifier "owned by the user" plus "self-serve" implicitly separates this from the manage_oauth_client sibling, though it never names that alternative.

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 read-only listing nature of the tool implies when it is appropriate, and the "owned by the user" scoping tells the agent this is a personal-scope enumeration. There is no explicit statement about when to use this versus manage_oauth_client, nor any mention of auth or account prerequisites.

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

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

With read-only and idempotent annotations already present, the description adds meaningful behavior: direct OAuth URLs are intentionally not exposed, account_id wins over platform when both are given, include_planned reveals future integrations, and credential platforms show credential_fields needed by connect_account. It does not cover rate limits or response size, but it goes well beyond the annotations.

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

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

The description is front-loaded and information-dense, but it is a single run-on paragraph with semicolons and repeated platform examples that duplicate the schema enums. It is not bloated, but it could be structured more clearly for an agent to scan quickly.

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

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

For a complex seven-parameter, three-view tool without an output schema, the description explains what each view returns and the key constraints an agent needs to call it correctly. Minor gaps remain, such as not describing workspace_id behavior beyond the schema, but overall it is complete enough for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds precedence rules (account_id wins over platform), default behavior (view=platforms), intended use of connection_url, and guidance to omit target to list live connection targets. Workspace_id and debug receive less description-level explanation, but the added semantics are useful.

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

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

The description clearly establishes that this tool retrieves platform metadata, settings schemas, and connection links, and breaks this down by view mode. It distinguishes the tool from siblings like list_accounts and connect_account by describing what each view returns, though the opening phrase is telegraphic rather than a full verb-led purpose statement.

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

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

It gives clear usage context for each view: platforms is the default, schema is preferred with account_id and is needed before Instagram native tags/collaborators, and connect_link should use connection_url in a logged-in browser. It does not explicitly state when not to use the tool, but the view-specific guidance is strong.

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

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

Goes well past the readOnly/idempotent annotations: it explains role-based visibility, that omitting workspace_id searches every workspace, the semantics of status=missed, the multi-field group_id match, the date-range-dependent default ordering, and the 366-day cap on counts. It also states that the output always reports whether all matching posts were shown, which is essential for correct paging 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?

Content is dense and mostly earns its place, but it is delivered as one long unbroken paragraph mixing filtering, paging, and the counts mode. Sectioning or front-loading the two-view distinction would make it far easier to scan for a 16-parameter 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 16-parameter read tool with no output schema, it covers everything an agent needs: filter semantics, defaults, paging loop, timezone handling, the dual-mode contract, and the one field worth surfacing (approval.pending_client_approval). Nothing material is left to inference.

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

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

Schema description coverage is 100%, so the baseline is 3 and the description largely restates the same facts (group_id matching, timezone behavior, scheduled_to inclusivity). It does add modest value by tying ordering to the presence of a date range and by clarifying that limit/offset/order are ignored under view=counts.

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

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

Opens with a concrete verb+resource+scope: posts across your workspaces and teammates', constrained by role and brand-locked seats. It also separates the two modes (view=list vs view=counts) inline, so an agent can distinguish this from get_post or list_analytics 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?

Explicit guidance for the counts view ("use it for 'how many' or 'is this month full' questions") and a mandatory paging directive (keep calling until everything is shown before drawing conclusions). It never names sibling alternatives like get_post or list_analytics, so routing between tools is left 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?

Beyond the annotations (read-only, non-destructive), the description provides critical behavioral constraints, such as requiring a 'Pro plan or higher,' which is a major operational constraint for an agent.

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?

While comprehensive, the description is slightly dense. However, every sentence contributes vital information regarding the suggestions' quality, operational constraints, or workflow integration, making it structurally sound.

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

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

Given its complexity as an AI-driven, evidence-based workflow tool, the definition is exceptionally complete. It covers content quality, usage requirements, workflow integration, and result handling.

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?

Since schema coverage is 100%, the description primarily serves to elaborate on defaults (status 'pending') and define the high-level filtering goals of the parameters rather than defining their internal data structure.

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 is highly specific, defining the tool as a source for 'proactive post suggestions' that are evidence-based and written in an 'account's learned voice,' clearly distinguishing it from general post listing 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 tool provides explicit usage guidance, detailing filtering options (account_id and status), how to handle large results (pagination via offset), and the required integration with other tools (using dismiss_suggestion).

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/destructiveHint=false, so safety is covered; the description still adds meaningful behavior beyond them: result scoping ('only brands you can see') and the fact that the response includes capability flags for pausing, resuming, and publishing missed posts. It does not describe error or empty-state behavior, so it stops short of 5.

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

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

Three tight sentences, front-loaded with the question the agent is likely asking, then the returned information, then the read-only constraint and the mutation alternative. No filler.

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

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

There is no output schema, and the description compensates by enumerating what comes back: workspace pause state, per-brand pause state, and permission flags. Combined with the schema's parameter documentation and the annotations' safety profile, 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?

The single workspace_id parameter has 100% schema description coverage, including the 'from whoami' and default-workspace semantics, so the schema carries the load. The description adds nothing about the parameter, which is acceptable at this coverage level but is baseline only.

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 plus the exact question it answers: 'Is publishing paused? Shows whether the workspace is paused, which brands are paused... and whether you may pause, resume, or publish missed posts.' It also explicitly separates itself from the mutation sibling manage_publishing_pause, so an agent can choose between them 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?

Clear routing: this is the read path, and 'Change it with manage_publishing_pause' names the alternative and the condition that selects it. What's missing is any precondition guidance about when the pause state matters (e.g., checking before create_post or before resuming publishing).

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, non-destructive, and closed-world, so safety is covered. The description adds real behavior beyond them: delivery history remains unavailable until switched on, and it never exposes the signing secret or request body — meaningful data-scope limits not derivable from annotations or schema.

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

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

Front-loads the primary list behavior, then the alternate view, then the caveats — three tight sentences with no filler. The phrase 'stays off until it is switched on' is slightly oblique about what must be enabled, a minor clarity cost but not wasted text.

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

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

Covers both modes and the notable data exclusions for a read-only, no-required-param tool with five optional params and no output schema. Missing only pagination guidance for limit/offset, which the schema partially addresses; nothing essential to invoking it correctly is absent.

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

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

Schema coverage is 60%, and the description only explains the view enum and the view=deliveries/webhook_id pairing, both partly echoed in the schema. It adds no semantics for limit, offset, or workspace_id, so it does not compensate for the remaining coverage gap. Baseline 3 is appropriate given the schema carries most parameter meaning.

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

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

States a specific verb (list) and resource (API webhook subscriptions) plus what the payload surfaces: event filters, active state, and most recent delivery status. It also delineates the two view modes, so an agent can distinguish this from create_webhook and manage_webhook 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 routes the deliveries case: use view=deliveries with webhook_id to read recent attempts for a single webhook. It gives clear context for when each view applies, but does not name sibling alternatives (create_webhook, manage_webhook) or state exclusions such as 'use manage_webhook to change active state'.

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/non-destructive, so the description isn't needed for the safety profile — yet it adds real value: permission requirements, per-role output variation (owners and admins also see key counts, connected AI apps and last use), and brand-scoped visibility. It does not disclose pagination or result-size limits, which is the main remaining behavioral gap for a listing tool.

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

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

Front-loaded with the core action, then payload, then permissions, then visibility caveats — a sensible order. It is a dense single paragraph with some stacked clauses ("from their own keys and AI apps"), but nearly 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?

No output schema exists, so the description must carry the return-value burden, and it does: it names the member fields, invite info, seat counts, and admin-only extra fields. Combined with the auth requirements, an agent could call this correctly; only pagination/result limits are 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?

With 100% schema description coverage on a single required parameter, the schema already explains workspace_id (sourced from whoami). The description only implies the workspace scoping and adds no format or acquisition detail beyond the schema, so baseline 3 applies.

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

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

Opens with a specific verb and resource ("List the people in a workspace") and immediately enumerates what is covered — members with role/status/brand access/API access, pending invites, and seats in use. An agent can distinguish this read-only roster tool from the sibling manage_workspace_member 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: an API key with the Manage team permission, and the note that any workspace member can list while brand-limited teammates only see accessible brand ids. What's missing is an explicit routing statement (e.g., "use manage_workspace_member to change a role"), so when-not-to-use is only implied by the verb contrast.

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, but the description goes well beyond them by disclosing what archiving actually destroys and what it does not: the brand leaves the active list, connected accounts stay connected, and scheduled posts still publish. It also surfaces the admin-only authorization requirement and the exact preview/confirm_id protocol.

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

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

The action-by-action structure is front-loaded and each sentence carries real information about prerequisites or consequences. The only waste is the repeated 'Pass confirm=true only after the user agrees' clause in both the create and update sections.

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

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

For an 8-parameter mutation tool with no output schema, the description covers all three action paths, required inputs, authorization, and the user-facing confirm gate, plus the non-obvious side effects of archiving. An agent has everything needed to invoke it correctly and explain the outcome to the user.

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

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

Schema description coverage is 100%, so every parameter including confirm, preview_id, and workspace_id is already documented in structured form; the description largely restates those constraints. It does reinforce the sequencing between the preview call and preview_id, but that is also present in the schema.

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

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

The first sentence gives a specific verb set and resource: 'Create, update, or archive a brand.' Each of the three actions is then enumerated with its own required inputs, so an agent can distinguish this management tool from the sibling list_brands (which is explicitly named as the source of brand_id).

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?

Guidance is explicit per action: create/update/archive are all 'admin only', create needs workspace_id 'from whoami when the key is not already scoped', and archive follows a preview-then-confirm sequence. The description does not name conditions for when-not to use this tool, but no sibling overlaps these mutations, so the routing gap is minor.

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

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

The annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotent, so the safety bar is lower, but the description still adds substantive behavior: update is reversible with no confirmation, delete is irreversible and admin-only, and reply/delete require a two-call preview then confirm flow with a preview_id. It does not describe the contents of the preview object or what happens if a preview_id expires, which keeps it just short of a 5.

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

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

The single dense paragraph is front-loaded and organized action-by-action, and nearly every clause carries a constraint an agent needs. It is slightly run-on, packing platform restrictions, reversibility, and the confirm flow into long sentences that would read faster as a short bulleted action list.

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, yet the description explains the only non-obvious return value an agent must handle, the preview plus preview_id from the preview call. For a 9-parameter multi-action mutation tool, the plan requirement, platform matrix, permission limits, and irreversibility are all disclosed, leaving no blocking gap.

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

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

Schema coverage is 100%, so the baseline is 3, and the description goes beyond it by tying parameters to actions and to each other, notably that confirm=true is only valid paired with the preview_id from the prior call and that type=private is Instagram-only while other platforms accept public replies only. It adds real conditional semantics the flat schema cannot express, though a few parameters (workspace_id, is_read scope) are left entirely to the schema.

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

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

The description states a specific resource (an inbox comment) and enumerates the three concrete operations with their own parameter sets: action=reply (comment_id, content), action=update (is_hidden/is_read), action=delete (comment_id). It is clearly separable from list_comments and manage_conversation because it disclaims listing/reading behavior and focuses purely on acting on an existing comment.

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 per action and names alternatives for blocked cases: 'Threads replies cannot be deleted, hide them instead' routes the agent from delete to update. It also specifies prerequisites (Pro plan or higher plus posts:write) and the required preview-then-confirm sequence for reply and delete, with update explicitly noted as needing no confirm.

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, the description discloses the Pro-plan-plus-posts:write permission requirement, the 24-hour messaging window that governs whether a send succeeds, per-platform cooldowns (30s, 60s for LinkedIn), and that the send is a two-step preview/confirm flow rather than an immediate side effect. These are exactly the operational facts an agent needs and none of them are recoverable from readOnlyHint/destructiveHint/openWorldHint.

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?

Dense but front-loaded: the scope and permission gate come first, then each action is introduced with an 'action=' token that mirrors the enum. It is a single semicolon-chained paragraph that would read better as bullets, but 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 an 8-parameter, two-mode tool with no output schema, it covers permissions, platform limits, rate limits, and the send workflow well. It does not say what the preview actually contains or what happens when the 24-hour window has lapsed, which are the remaining questions an agent would have before its first call.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: it pairs conversation_id and content with the 24-hour window constraint, frames confirm/preview_id as a workflow rather than a lone boolean, and ties account_id to per-platform cooldown and comments-only behavior for Threads and LinkedIn.

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?

Each action is given a specific verb and resource: 'send a DM reply in an Instagram or Facebook Page conversation' and 'pull the latest Instagram, Facebook Page, Threads, or LinkedIn inbox data for one account.' Platform scope and exclusions ('Threads has no DMs') let an agent distinguish it from siblings like list_conversations, list_comments, and manage_comment without opening a schema.

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

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

The description clearly separates the two invocation modes and lays out the exact preview-then-confirm sequence for send, including showing the preview to the user before confirming. It also names list_conversations and list_accounts as ID sources. It stops short of explicitly contrasting this tool with manage_comment or list_comments for comment handling, leaving that 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?

The description goes well beyond the annotations by disclosing that raising slots charges the saved card, that extra_accounts is a desired TOTAL with 0 removing everything, that 3D Secure or a decline returns a payment link and adds nothing, and that the operation is Owner-scoped with billing:write. The annotations already flag destructiveHint and idempotentHint, and the description reinforces rather than repeats them; only the exact consequence for existing slots when lowering (proration/refund behavior) is unstated.

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

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

The text is front-loaded with the operation, then the financial warning, then permissions, then the workflow, then the failure mode — a sensible ordering. The telegraphic style ('MONEY:', 'billing:write', 'add 20+ at a time') packs a lot in but reads as compressed shorthand in places, slightly taxing on first parse.

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

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