Influence

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

Annotations already declare readOnly=true, idempotent=true, destructive=false, so safety is covered elsewhere. The description adds some behavioral signal, notably that results are paginated and that 'account eligibility determines availability', plus the claim that platform is a stable identifier. The long provider mapping is return-value orientation rather than behavioral disclosure, and no rate limits or ordering guarantees are mentioned.

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 purpose is correctly front-loaded in the first sentence, which is good structure. However, the 45-entry semicolon-separated provider label dump is a wall of text that dominates the description and is not formatted for scannability. It is reference material that would be better placed in structured 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?

An output schema exists, so the description needn't restate return shapes, and annotations cover the safety profile. What remains missing for a three-parameter list tool is the meaning of the kind enum and how pagination is driven. The provider label list partially compensates on output interpretation but the input side is left thin.

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

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

Schema description coverage is 0% across three parameters, so the description must carry the burden and does not. The kind enum values (social, whatsapp) are never explained, the limit bound of 1-20 is not mentioned, and cursor pagination usage is only implied by the word 'paginated'. The provider labels describe an output field, not any input parameter, so they do not compensate.

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

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

The opening sentence gives a specific verb and resource: 'Returns paginated owned accounts, stable identities and core-post eligibility.' An agent can tell this is a read/list tool for accounts. It stops short of differentiating from sibling account-list tools such as insightsAccountList or vkDestinationList, and the phrases 'stable identities' and 'core-post eligibility' are jargon the agent must interpret.

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

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

There is no when-to-use guidance, no statement of when to prefer this over sibling list tools, and no explanation of the social vs whatsapp choice the kind parameter demands. The provider-label block is reference data, not usage direction. An agent gets no help deciding whether to call this tool at all.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds real edge-case behavior: missing reports return null, unknown cost and unavailable comparisons remain explicit, and oversized reports surface a signed-in review path. These are non-obvious behaviors an agent could not infer from the schema or annotations.

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

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

Three tightly packed sentences, front-loaded with the primary return content and followed by edge-case behavior. No wasted filler, though the density borders on terse for a first-time reader.

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

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

With an output schema present, return values need not be re-explained, and annotations cover the safety profile; the description fills the remaining gap by disclosing null, unknown-cost, and oversized-report handling. Only the parameter's role/format is left unaddressed.

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

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

There is a single required parameter (auditPublicId) with 0% schema description coverage, and the description never mentions it or its format, other than implying the record is retrieved by id. The schema carries a uuid format/pattern, but the description adds no parameter meaning beyond that.

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 (Returns) and resource (one owned private ad review), scoped to a single record, which implicitly contrasts with the list-oriented adAuditList sibling. It is clear, but it never names the sibling to make the single-vs-list distinction 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?

Usage is only implied: you fetch one review by id. There is no statement of when to use this versus adAuditList, nor any prerequisite or exclusions. Adequate but with a clear gap.

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, closed-world behavior, so the safety profile is covered. The description adds real value beyond that: pagination, stable IDs, current job states, and the constraint that saved reviews stay readable during processing outages.

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

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

Two tight sentences that front-load what is returned and follow with the only non-obvious operational caveat. No filler or restated title content.

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

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

For a read-only list tool with two optional pagination params and an output schema that covers return values, the description is nearly sufficient. The remaining gap is that it does not point to adAuditGet for retrieving a single review.

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

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

Schema coverage is 0%, so the description must carry the load. 'Paginated' hints at the limit/cursor pair, but it never explains the 1-20 limit bound or the cursor semantics, leaving the two optional parameters largely undocumented in both places.

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 ('Returns paginated saved private ad reviews') plus the notable payload contents (stable IDs, current job states). It is implicitly distinct from the singular sibling adAuditGet, but the description never explicitly names that alternative, so the differentiation is left to inference.

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

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

Usage is implied by the availability note ('Saved reviews remain readable while new processing is unavailable'), which tells the agent the tool still works when processing is down. However, there is no explicit when-to-use statement and no routing to adAuditGet for fetching an individual review.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuine behavioral value beyond them: it discloses that absent context is simply omitted rather than erroring, and that no website research is performed — both useful expectations to set. Return format is not described, but an output schema exists, so that is acceptable.

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

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

Two tightly written sentences, both earning their place: the first defines what is returned, the second bounds the behavior. The core purpose is front-loaded with no filler.

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

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

With an output schema present, the description need not explain return values, and the zero-parameter, read-only nature is fully covered by annotations plus the two scope clauses. It is complete enough for correct invocation; only an explicit alternative for the research case 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?

The tool takes zero parameters, so there is nothing for the description to document; baseline 4 applies. No misleading parameter claims are made.

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 (returns) and resource (saved, confirmed company facts plus customer-authored brand guidelines), which is more precise than the title 'Read brand context'. It is clear, though it does not name any sibling by contrast; the 'no website research' clause is a scope statement rather than a sibling disambiguation.

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 clause 'Missing context remains absent; this operation performs no website research' implies when this tool is appropriate (reading already-saved context) and when it is not (when fresh research is needed). However, it names no alternative tool for the research case, so the routing guidance is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context about return fidelity and ordering, including that media retains full verified facts in saved order and that a single image/video has a reference.

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 compact and front-loads the returned content. The second sentence is dense but relevant; it is not padded with boilerplate, though it could be phrased more directly.

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

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

With an output schema and rich annotations, the description is not required to explain every return detail, but it still omits the campaignId input context and does not distinguish this from sibling campaign reads. It is adequate for understanding output shape but incomplete for invoking the tool correctly without relying entirely on 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?

The tool requires a campaignId, but the description never mentions the parameter, its role, or its format. Schema description coverage is 0%, and the only parameter semantics come from the schema property name and pattern, so the description does not compensate for the gap.

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

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

The description states a specific read operation and enumerates what is returned: saved text, settings, ordered media, and per-destination delivery status. It does not explicitly differentiate this tool from siblings such as campaignList or campaignPlanGet, so it falls short of a 5.

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

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

There is no explicit when-to-use guidance, no mention of alternatives like campaignList, and no conditions for choosing this tool. The read-only nature is carried by annotations and the title, not by the description.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds the pagination concept ('continuation cursor'), which is genuine context beyond annotations, but does not explain cursor semantics, default page size, or end-of-results behavior.

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

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

A single front-loaded sentence with no filler and no redundancy. It is efficiently sized, though the brevity contributes to the gaps noted in other dimensions.

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

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

An output schema exists, so return values need not be described, and annotations carry the safety profile. Still, for a paged list tool with fully undocumented parameters the description should at least cover limit/cursor usage, which it only partially does.

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

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

Schema description coverage is 0%, so both parameters depend on the description. It hints at the cursor's role but says nothing about the limit parameter, its default, or the maximum of 20 enforced in the schema. The description compensates only for one of two undocumented parameters.

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?

"Returns saved compositions with a continuation cursor" gives a resource (saved compositions/campaigns) and a mechanic, but uses the verb "returns" rather than "lists" and never names the sibling it differs from (campaignGet, campaignDraftSave, etc.). An agent can infer it is a listing endpoint, but the purpose is only implied 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?

There is no when-to-use, when-not-to-use, or alternative routing at all. With ~70 siblings including campaignGet and many *List tools, the description gives no signal about when this paged list is the right choice over a single fetch.

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 beyond the annotations by disclosing credit consumption, that output is persisted planning text plus optional image ideas, and explicit negative scope (no media produced, no publishing). It does not explain the confirmation-capability/idempotency protocol that the schema's dependentRequired block implies, which matters for a credit-spending, destructiveHint=true call.

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

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

Three sentences, zero filler, with purpose front-loaded before the revision constraint and the negative-scope boundary. Slightly dense in the opening clause, which packs three input categories into one phrase, but nothing is redundant.

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

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

With 14 parameters, deep nesting and a destructiveHint=true annotation, the description covers the core lifecycle and (since an output schema exists) needn't explain returns. However, it is silent on the idempotency/confirmation fields the schema pairs together and on why a planning tool accepts whatsAppTargets, leaving real gaps for a high-complexity mutation.

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 36% across 14 parameters, yet the description supplies meaning for only two of them (planPublicId as 'the plan identifier', expectedVersion as 'current expectedVersion'). 'Owned accounts, saved media and brand context' loosely maps to connectionSettings/mediaAssetIds/preferences but leaves brief, title, action, choice, requestId and whatsAppTargets undocumented in both places.

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 ('Queues one AI text-planning turn') and names its inputs (owned accounts, saved media, brand context). The closing clause ('creates no image, video or audio and performs no publishing') cleanly distinguishes it from imageGenerationStart, campaignReviewExecute and campaignScheduleBatchExecute without needing their schemas.

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

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

Gives the condition that selects revision mode ('Revisions require the plan identifier and current expectedVersion') and lists adjacent operations it is not (image/video/audio generation, publishing). It never names a sibling tool explicitly for those alternative paths, so routing is implied rather than 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 read-only, idempotent, non-destructive, and closed-world behavior, so the description does not need to restate safety. It adds useful behavioral context by listing the returned artifacts and warning that image job access depends on connection permissions and visible tools.

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

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

The description is two focused sentences, front-loaded with what the tool returns. The second sentence adds a relevant permission caveat without unnecessary 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?

Given the output schema and rich read-only annotations, the description is sufficiently complete about return contents and permission sensitivity. The main remaining gap is that the sole input parameter is not described anywhere, and sibling usage is not clarified.

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 input schema has 0% description coverage, so the description must compensate for the lone required parameter. It never mentions planPublicId or explains what identifier is expected, leaving parameter meaning only inferable from the name and schema constraints.

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

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

The description uses a clear read verb and names the specific resource: an owned AI plan, with exact version, conversation, image ideas, planning job, and credits. It distinguishes the tool as a getter in practice, but it does not explicitly contrast it with siblings such as campaignPlanGenerate or campaignGet.

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 implies the tool retrieves plan details by ID, but it gives no explicit when-to-use guidance or alternatives. The note about image job access depending on connection permissions and visible tools is a caveat, not usage direction.

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

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

Annotations declare the safety profile (not read-only, not destructive, not idempotent), and the description adds a key behavioral fact beyond them: saving answers does not approve or publish. It also discloses the shape of the returned state. It does not address versioning/permission expectations, which the schema handles, so this is solid rather than exhaustive.

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

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

Four dense sentences, front-loaded with the two modes before constraints and return shape. Every sentence carries meaning, though the final return-value sentence is somewhat redundant given an output schema exists.

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

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

For a mutation tool with no required parameters, a rich nested schema, and an output schema plus annotations covering safety, the description supplies the missing behavioral context: call modes, the never-infer rule, and the save-vs-approve distinction. An agent has enough to invoke it correctly.

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

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

Schema description coverage is 50% across 8 params. The description clarifies the two call modes (reviewId + tiktokSettings vs. campaign creation fields) and stresses that all TikTok answers/consent must be supplied, adding real meaning. It says nothing about scheduledFor, campaignId, expectedVersion, or the idempotency/confirmation pair, leaving half the parameters reliant on the schema.

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

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

States specific verbs and resources: creates an exact pending campaign review, or saves explicit TikTok answers via reviewId/tiktokSettings to produce a replacement pending review. It implicitly distinguishes itself from campaignReviewApprove/Execute by noting 'Saving choices does not approve or publish', though it never names those siblings directly.

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

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

Gives agent-facing process guidance ('Ask for all missing TikTok choices and applicable consent together; never infer answers') which is genuinely useful. However, it never states when to pick this tool over campaignReviewApprove, campaignReviewExecute, or campaignDraftSave, so tool selection still requires inference.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is partly covered. The description adds genuinely new context beyond them: a private expiring capability is required per exact review, all attached media must have been inspected, and 'rejected means nothing was applied' documents atomicity of failure. It stops short of describing what a successful execution irreversibly commits or any rate/scope limits.

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

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

Three sentences, front-loaded with the core action, and each sentence carries distinct information (trigger, requirements, outcome semantics). The middle sentence is somewhat dense and packs two separate constraints together, but there is 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?

An output schema exists, so return-value documentation is not strictly required, yet the description usefully summarizes the receipt-versus-rejection outcome anyway. For a destructive mutation with three mutually exclusive action variants (approve, update_tiktok, approve_batch), the description covers the approval path and gestures at TikTok settings but never mentions batch approval, leaving one schema branch undescribed.

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 meaning beyond the schema: the 'capability' string is characterized as private and expiring and required for every review, and 'all attached media to be inspected' explains the intent of viewedMediaAssetIds. That is useful semantic enrichment rather than restatement, though it does not address the update_tiktok or approve_batch variants.

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: it 'executes the exact reviewed campaign.' That is concrete and actionable, and the qualifier 'exact reviewed campaign' narrows scope. It does not, however, differentiate itself from close siblings such as campaignReviewExecute, campaignReview, or campaignReviewGet, which an agent could plausibly confuse with it.

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 a clear triggering context ('after an explicit click in the Influence review UI') and a precondition ('Complete any pending TikTok choices before approval'). What is missing is an explicit statement of when to choose this over campaignReviewExecute or campaignReview, so no alternatives are named.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds non-obvious behavior: execution runs through a durable scheduler, happens exactly once, and chat-sourced approval is recorded as client-reported rather than verified. It does not explain how the required _confirmationCapability is obtained, which is the main remaining behavioral gap.

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

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

Three sentences, front-loaded with the action and mechanism, then the gating condition and the platform-specific prerequisite. Dense but every sentence carries a distinct constraint; only the credential/preparation step is missing rather than any filler being 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?

An output schema exists, so return values need no explanation, and the destructive/non-idempotent nature is covered by annotations and the idempotency-key schema text. However, the dependentRequired pair _idempotencyKey + _confirmationCapability is a real invocation hurdle the description never addresses, leaving an agent unsure how to legally construct the 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 only 50%, and the description compensates by explaining the semantic weight of approval: it must be 'approved' and only after fresh explicit user approval of the complete payload. That clarifies the const parameter beyond the schema literal, and the role of reviewId as the exact approved review is implied. It still leaves the preparation source of _confirmationCapability unexplained.

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: executes an exact approved review once via the durable scheduler. It is distinguishable from campaignReviewApprove (approval) and campaignScheduleBatchExecute (batch), though it never names those siblings explicitly. The 'once' scoping and 'durable scheduler' mechanism make the action concrete rather than tautological.

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 precondition: send approval: approved only after fresh explicit user approval of the complete post, media, settings and time, and routes prerequisite consent through campaignReview or the review card for TikTok Direct. It stops short of stating when not to use this tool or explicitly naming the approve/prepare alternative, so it is strong context without full exclusion guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the meaningful 'owned' access scoping and enumerates what is returned (content, state, committed operation result). It omits what happens on a missing/unowned reviewId (error vs empty) and any pagination or size considerations.

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

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

A single tight sentence with the core action front-loaded and no filler. The phrase 'any committed operation result' is slightly opaque jargon, which keeps it just short of ideal.

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

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

With an output schema present, return values need not be explained, yet the description still summarizes the payload usefully. For a one-parameter, read-only tool with full annotation coverage this is nearly complete; only the sibling-routing guidance is missing.

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

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

Schema description coverage is 0% for the single reviewId parameter, but the schema does supply format constraints (pattern, 1-128 chars) and the parameter name is self-explanatory. The description mentions the review being retrieved but adds no semantic detail beyond the schema, so it neither compensates for the gap nor misleads.

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 ('Returns') and resource ('an owned review') plus the payload shape: complete content, current state, committed operation result. An agent can distinguish this from sibling retrievers like campaignGet or campaignPlanGet. It does not, however, explicitly differentiate itself from campaignReview or the approve/execute 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?

There is no when-to-use, when-not-to-use, or alternative guidance. The sibling set contains campaignReview, campaignReviewApprove, and campaignReviewExecute, and the description never says when to fetch versus mutate/approve/execute. Usage must be inferred entirely from the name.

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

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

The annotations already declare the operation is destructive, open-world, and non-idempotent. The description adds meaningful behavioral detail: atomic scheduling, rollback of new scheduling for invalid or stale items, and replay behavior retaining committed job identifiers. It does not disclose auth requirements or rate limits, but it goes beyond what the annotations provide.

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

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

The description is front-loaded with the core action and its limits, and each sentence carries useful information. The prerequisite sentence about TikTok choices and consent is placed after approval context, which is slightly less ideal, but overall it is dense and efficient.

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

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

Given a complex, destructive batch-execution tool, the description covers purpose, limits, approval semantics, prerequisites, rollback, and replay behavior well. Output schema exists, so return values need not be explained. It is slightly incomplete on how the tool relates to sibling review/approval tools and on the confirmation capability parameter.

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

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

Schema description coverage is 67%, so the schema already documents some fields. The description adds substantial meaning beyond the schema: items must be up to 10 exact approved schedule reviews, one approval covers the complete displayed batch, at most 50 deliveries apply, and invalid or stale items cause rollback. It does not explain the _confirmationCapability parameter or define reviewId, leaving some gaps.

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

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

The description uses a specific verb and resource: schedules approved schedule reviews in a batch. It also states concrete scope limits: up to 10 exact approved reviews and at most 50 deliveries, with atomicity. However, it does not explicitly distinguish this execute tool from sibling tools such as campaignScheduleBatchReview or campaignReviewExecute.

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 prerequisites: items must be exact approved schedule reviews, one user approval must cover the displayed batch, and required TikTok choices and consent must be saved first. It does not name alternatives or state when not to use the tool, but the context for correct invocation 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 destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the mutation/safety profile is covered. The description adds genuinely non-obvious behavior beyond that: batch atomicity ('Invalid items roll back the batch') and the return shape ('compact review receipts'). The idempotency/confirmation retry flow is left to the 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 short sentences, front-loaded with scope then behavior then outcome. Nearly every clause earns its place, though 'including one post' is redundant with the '1–10 finished posts' bound and causes a moment of ambiguity.

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

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

With an output schema present, return values need not be explained, and annotations cover safety. But for a complex batch-write tool the description omits the surrounding workflow — that this is the preparation step feeding campaignScheduleBatchExecute and a confirmation capability — leaving the agent to reconstruct the flow from schema property names.

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

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

Schema coverage is 67%, and the description contributes an aggregate constraint the schema cannot express — 'at most 50 social destinations and WhatsApp recipients' across the batch, versus the per-post maxItems of 20. The 1–10 item bound also restates the schema's maxItems as a usable range. It adds real value, though it says nothing about the idempotency/confirmation parameters.

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 ('Saves 1–10 finished posts and pending schedule reviews together') and quantifies scope (1–10 posts, 50 destinations). However it never names the sibling campaignScheduleBatchExecute, nor does it clarify that this is the prepare/review half of a two-step flow, so an agent must infer the relationship from the name alone.

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

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

There is no when-to-use guidance and no mention of the obvious alternative, campaignScheduleBatchExecute, or the confirmation capability that the schema exposes. The agent gets no signal about when this review step is appropriate versus executing or saving a draft.

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=false, so the safety profile is covered. The description adds a genuine semantic caveat — that a native callback does not identify a vendor — which is useful context beyond the annotations, but it says nothing about auth requirements, freshness/caching, or error 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?

Two sentences, no filler, with the core purpose front-loaded and the callback caveat relegated to second position. The second sentence is terse and slightly under-contextualized, but it earns its place by flagging a real interpretation gotcha.

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

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

With an output schema present, the description need not detail return values, and with zero parameters and full read-only annotations, the surface area is small. The description adequately covers scope plus the one non-obvious caveat, though it could note whether the call requires an established connection.

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 no parameter semantics to document beyond the schema. The description correctly adds no redundant parameter discussion, and the input schema is trivially complete.

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

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

States a specific verb and resource ('Returns the current connection's...') and enumerates the exact state it exposes: permissions, renewal mode, token expiry, callback class, last account read. This is clearly distinguishable from siblings like accountList or profileGet, which deal with accounts and profiles rather than connection/session state.

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

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

There is no statement of when to call this versus alternatives (e.g., profileGet or accountList), no prerequisites, and no exclusions. The only guidance-like content is the caveat about native callbacks, which concerns interpretation of results rather than tool selection.

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. The description adds useful behavioral context beyond annotations: the owned-account prerequisite, provider availability, and pagination guidance ('Follow nextCursor until done, keeping the same connection and search fields'). The mention of 'search fields' is slightly inaccurate since no such parameters exist, but the pagination instruction is valuable.

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

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

Two tight sentences with the core action front-loaded and no wasted words. The slightly confusing mention of 'search fields' prevents a perfect score.

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

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

An output schema exists, so return values need not be explained. The description covers prerequisites, pagination, and account requirements adequately for a simple list tool. The inaccurate reference to 'search fields' is a minor completeness gap.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description reinforces cursor usage by naming 'nextCursor' and 'connection' but does not add new semantic details beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'List available publishing organizations.' The title adds the Dev.to platform, but the description itself does not explicitly distinguish this tool from sibling list tools like hashnodePublicationList or ghostAuthorList.

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 provides a prerequisite ('Requires an owned active account and current provider availability') but does not say when to use this tool versus alternatives or include any exclusions. Usage is implied by the prerequisite rather than explicitly guided.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious context: an owned active account is required, results depend on provider availability, and cursoring must reuse the same connection and search fields. It does not cover rate limits or failure modes, keeping it short of a 5.

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

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

Two sentences, zero filler, with the capability stated first and the constraints and pagination protocol following. Every clause carries information an agent needs to call the tool correctly.

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

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

An output schema exists, so return values need not be described, and both required prerequisites plus the cursor loop are covered. For a simple read-only list tool this is nearly complete; only behavior on an inactive account or an expired cursor is left unstated.

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

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

Schema description coverage is 100%: 'cursor' is documented as the nextCursor from the prior page and 'connectionId' as the value returned by accountList. The description echoes the cursoring discipline without adding format or syntax detail, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific verb and resource ('List available article tags'), and the Dev.to platform scope is carried by the tool name alongside siblings like discourseTagList and ghostTagList. It is clear and actionable, but the description itself never names Dev.to or explicitly contrasts itself with the other tag-listing 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?

It states prerequisites ('Requires an owned active account and current provider availability') and how to iterate pages, which is real usage context. It gives no when-not-to-use condition and names no alternative tool for tag discovery, so guidance is contextual but incomplete.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower; the description adds real value by disclosing pagination behavior (follow nextCursor to completion, hold the same connection and search fields). The only blemish is the reference to 'search fields' that do not exist in the 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 short sentences with purpose front-loaded, followed by prerequisites and pagination instructions. No filler, though the trailing 'search fields' clause is a wasted/incorrect detail that slightly mars an otherwise tight structure.

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

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

An output schema exists, so return values need no explanation, and annotations fully carry the safety profile. The description covers prerequisites and pagination, leaving little an agent needs missing; only the stray 'search fields' reference creates minor ambiguity.

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 cursor and connectionId are fully documented in the schema itself. The description only alludes to the cursor via 'nextCursor' and adds no format, constraint, or meaning beyond what the schema already provides, so the baseline 3 applies.

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

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

States a specific verb ('List') and resource ('Discord publishing channels'), and the platform qualifier 'Discord' distinguishes it from the many sibling *ChannelList tools (slackChannelList, teamsChannelList, mattermostChannelList). It is clear and near-complete, though it does not explicitly contrast scope against those 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 preconditions ('Requires an owned active account and current provider availability'), which tells the agent when the call is viable, but there are no exclusions and no named alternative (e.g., a channel search tool) for the case where this is not the right choice. Usage is implied rather than decisive, matching a 3.

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

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

Annotations already carry the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description earns credit for going beyond them: it discloses the account/provider preconditions and the pagination loop ('follow nextCursor until done'). It does not describe rate limits or what happens when provider availability is false, leaving 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?

Three short sentences, front-loaded with purpose, then prerequisites, then pagination mechanics. Nothing is padded, but the trailing 'search fields' clause is an unearned ambiguity rather than useful content.

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

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

An output schema exists, so return values need no explanation; the description covers the two things the structured fields cannot: preconditions and the pagination contract. It is nearly complete, with only the unexplained 'search fields' reference and no note on failure when the account or provider is unavailable.

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 the baseline is 3, but the description adds real usage semantics for the cursor parameter: iterate until done while holding the connection constant. The reference to 'search fields' is vestigial though — no such field exists in this schema, which slightly muddies the pagination instruction.

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

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

The description gives a specific verb and resource plus a meaningful scope filter: 'List forum categories where the connected user can create topics.' That distinguishes it in substance from discourseTagList and discourseTopicSearch, though it never names a sibling explicitly.

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

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

It states applicability conditions clearly ('Requires an owned active account and current provider availability') and the create-topics scope implies when this tool is the right pick. It stops short of naming alternatives or stating when NOT to use it, 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is its prerequisites and multi-page pagination contract ('keep the same connection... until done'). That is genuinely useful behavioral context beyond the structured fields, though it omits rate limits or failure 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?

Three short sentences, front-loaded with the core action and then prerequisites and pagination. Little waste, though the trailing 'search fields' clause adds ambiguity rather than value.

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

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

An output schema exists, so return values need not be explained, and the description covers prerequisites and the pagination loop. It is adequate for a simple read-only list tool; only failure/edge-case behavior is absent.

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

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

Schema coverage is 100%, so both parameters are fully documented in the schema, which sets the baseline at 3. The description adds only a pagination hint via 'nextCursor'; the reference to 'search fields' is slightly confusing since this tool exposes no search parameters.

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 forum topic tags') scoped to the connected user, which is clear enough to distinguish from discourseCategoryList and discourseTopicSearch by inference. It does not, however, explicitly name those siblings to route the agent.

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

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

The description gives prerequisites ('owned active account and current provider availability') and pagination guidance ('Follow nextCursor until done'), which implies usage context. It never states when to prefer this tool over the sibling tag/category listers or any exclusions, leaving selection to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the account/availability precondition and the rule that cursor pagination must keep the same connection and search fields.

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

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

Three short sentences with the purpose front-loaded and no filler. Slightly terse given the missing q semantics, 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?

An output schema exists so return values need no explanation, and annotations cover the safety profile. Still, the description never says what q matches (titles, content, tags) or what 'visible' means, leaving the core search behavior underspecified for an open-world search 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 67%; the cursor and connectionId descriptions already exist in the schema, and the description largely restates them ('same connection and search fields'). The q parameter (the primary search input) has no description anywhere, so the description does not compensate for that gap.

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

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

States a specific verb and resource ('Find a visible forum topic to reply to'), which is clearly distinguishable from the sibling list tools discourseCategoryList and discourseTagList. However, it never names those siblings or otherwise routes the agent among the Discourse tool family.

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 prerequisites ('Requires an owned active account and current provider availability') and pagination guidance ('Follow nextCursor until done'), but no explicit when-to-use versus alternatives such as discourseCategoryList for browsing rather than searching. Usage is implied rather than directed.

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 closed-world behavior, so the safety profile is covered. The description adds real value beyond that: the precondition of an owned active account with provider availability, and the pagination protocol of following nextCursor while holding the same connection.

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

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

Three short sentences, well front-loaded: purpose first, then preconditions, then pagination guidance. Efficient, though the trailing 'and search fields' clause introduces a concept not present in the schema and adds mild ambiguity.

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

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

With an output schema handling return values and annotations covering safety, the description only needs to add prerequisites and pagination behavior, both of which it does. The only minor gap is that 'search fields' is referenced without a corresponding parameter.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning to the cursor parameter by specifying it must be followed 'keeping the same connection and search fields', reinforcing the schema's 'this exact tool and input' note. The 'search fields' mention is slightly odd given no search parameter exists.

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 ('available publishing teams'), so the agent knows exactly what it returns. It does not explicitly differentiate itself from the many sibling *List tools, but the Dribbble-team resource is unambiguous and unique in the toolset.

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

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

Provides prerequisites ('Requires an owned active account and current provider availability') which is useful context for when this call will succeed. It stops short of naming an alternative or stating when-not-to-use, so usage is only implied.

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 the safety profile is covered. The description adds genuinely new behavior beyond the annotations: oversized documents hard-fail instead of silently truncating, and the tool performs no provider refresh or publishing. That is exactly the kind of consequence an agent needs, though a note on error shape/pagination is absent.

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, with the resource scope and lookup key front-loaded before the behavioral caveats. The second sentence packs two distinct constraints (oversize failure, no refresh/publish) into one clause, which is efficient but slightly dense.

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

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

For a one-parameter read-by-id tool with an output schema (return shape need not be described) and full annotation coverage, the description supplies the missing pieces: identifier provenance and failure semantics. It is essentially complete, with only the id-format constraint left unaddressed.

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

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

Schema coverage is 0% and there is a single required `id` with no description in the schema, so the description must carry the meaning — and it does, specifying the value is a 'search identifier' (derived from a prior search, not an arbitrary key) and that its resolution yields source URL and provenance. A minor gap remains on length/format constraints.

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 (Read) and enumerates the exact resource types it resolves (brand, saved campaign, AI plan, cached Insights document) plus the lookup key. It's clearly distinct from list/search siblings, though it never explicitly names `search` as the tool that produces the identifier, so the sibling routing is only implied.

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

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

Implies the precondition that the caller must already hold a 'search identifier', and gives two explicit exclusions: no provider refresh and no publishing. It never states when-not to use it in relation to a specific sibling (e.g. insightsRefresh or search), so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior: account/provider eligibility gates and the constraint to reuse the same connection and inputs across pages. It omits any note on ordering or result caps, keeping it short of a 5.

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

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

Three short sentences, front-loaded with what the tool returns, then prerequisites, then pagination. Every sentence carries actionable content with no filler.

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

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

With an output schema present, return values need not be described, and the prerequisites plus pagination loop cover what an agent needs to call it correctly. The only soft spot is the reference to 'search fields' when the schema exposes no search parameters, which could mildly confuse a caller.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema; baseline is 3. The description reinforces the cursor loop ('Follow nextCursor') and connection reuse, but adds no format or constraint detail beyond what the schema provides.

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

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

States a specific verb and resource ('List authors available for this publication'), which cleanly separates it from the other ghost* siblings (ghostNewsletterList, ghostTagList, ghostTierList). An agent can identify the resource 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 real preconditions ('Requires an owned active account and current provider availability') and pagination guidance ('Follow nextCursor until done, keeping the same connection'). It stops short of naming an alternative tool, but the siblings operate on different resources so there is little ambiguity to resolve.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context the annotations omit: that selecting a newsletter triggers email sends on article publish, plus the account-ownership and provider-availability constraints. This is valuable disclosure beyond structured data.

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

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

Three tight sentences, front-loaded with what the tool returns, followed by prerequisites and pagination. Every sentence carries information, with only minor redundancy around the cursor guidance already implied by 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?

Covers purpose, preconditions, pagination, and a hidden side effect, and an output schema exists so return values need no explanation. Nothing critical is missing for correct invocation, though the reference to non-existent 'search fields' is a small inconsistency.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema, and the baseline is 3. The description references 'nextCursor' and 'search fields', but no search-field parameter exists here, so it adds little beyond restating cursor semantics and introduces a slightly off-target detail.

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

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

States a specific verb+resource+scope ('List active newsletters') that immediately distinguishes it from sibling list tools like ghostAuthorList, ghostTagList, and ghostTierList. An agent can tell what it retrieves 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 real preconditions ('Requires an owned active account and current provider availability') and pagination instructions ('Follow nextCursor until done, keeping the same connection and search fields'). It stops short of naming an alternative tool or stating when not to use it, 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?

Annotations already declare read-only, idempotent, non-destructive behavior, but the description adds meaningful context: account ownership, provider availability, and cursor pagination consistency. It does not cover failure modes or rate limits, but the added behavioral detail exceeds the annotation baseline.

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

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

Three short sentences, front-loaded with purpose and followed by prerequisites and pagination. The only slight drag is the phrase 'search fields,' which has no corresponding parameter in this 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 read-only list tool with a complete input schema, output schema, and annotations covering safety, the description supplies the remaining operational context an agent needs: account requirement, provider availability, and pagination handling. Nothing critical is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description reinforces that cursor pagination must keep the same connection and search fields. However, those points largely restate or go beyond the schema without adding detailed parameter meaning, and 'search fields' is not an input parameter here.

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

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

The description opens with a specific verb and resource ('List article tags for this publication'), making the action unambiguous. It does not explicitly differentiate Ghost from sibling tag-list tools such as devtoTagList or wordpressTagList, so it falls short of a 5.

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

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

It states a clear precondition—owned active account and current provider availability—and explains pagination behavior. It gives no explicit when-not-to-use guidance or comparison to sibling tag-list tools, so 4 rather than 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, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious behavioral context: an owned active account is required, availability depends on the current provider, and pagination must preserve the same connection and search fields. That is real added value beyond the structured fields.

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

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

Three short sentences, zero filler. Purpose comes first, prerequisites second, pagination mechanics last — properly front-loaded and every sentence earns its place.

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

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

An output schema exists, so return values need not be explained. The description covers what the tool returns conceptually, the account/provider prerequisites, and the pagination contract, which is everything an agent needs for a read-only two-parameter list tool.

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

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

Schema description coverage is 100% and both parameters are documented in the schema, including the connectionId pattern and cursor provenance, so the baseline is 3. The description only lightly reinforces cursor semantics ('keeping the same connection and search fields') without adding format or syntax detail beyond what the schema already states.

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

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

States a specific verb and resource ('List membership tiers') with a scope qualifier ('available for article visibility'), which is enough to separate it from ghostAuthorList, ghostNewsletterList and ghostTagList. It stops short of explicitly naming or contrasting with any sibling, so it lands just under the top band.

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 ('Requires an owned active account and current provider availability') and explicit iteration instructions ('Follow nextCursor until done, keeping the same connection and search fields'). There is no when-not-to-use or named alternative, but the context for invoking it correctly 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 readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds real context beyond that: an account-ownership and provider-availability precondition plus explicit pagination behavior (follow nextCursor until done, keep the same connection). It does not mention rate limits or failure modes.

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

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

Three short sentences, front-loaded with purpose then prerequisites then pagination; little waste. The trailing 'and search fields' clause is a minor inaccuracy that costs a point.

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 paginated list tool with an output schema (return shape need not be explained) and full schema coverage, the description supplies the prerequisites and the pagination contract an agent needs. Nothing essential is missing.

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

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

Schema description coverage is 100% for both cursor and connectionId, so the schema already carries their meaning; baseline 3 applies. The description references nextCursor and the connection only obliquely and even mentions 'search fields' that do not exist as a parameter on this tool, adding no real semantic value.

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

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

States a specific verb (List) and resource (available article publications), so an agent immediately knows this is a paginated read of Hashnode publications. It does not explicitly name Hashnode or distinguish itself from the many other *List siblings (devto, ghost, wordpress), so it stops short of a 5.

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

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

Gives prerequisites ('requires an owned active account and current provider availability') which tells the agent when the call can succeed, but offers no when-to-use vs alternative guidance and names no sibling. Adequate context, no routing.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description goes further with value-bearing caveats: outcomes cycle queued/running/final, credit reservations vs authoritative settled costs, unknown cost stays null, and needs_review is not success.

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 resource and scope front-loaded and no filler. The second sentence is telegraphic ('needs_review is not success'), which is efficient but borders on cryptic.

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

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

An output schema exists, so return-shape detail is not required, and the description supplies the interpretation quirks (null cost, needs_review semantics) that the schema alone would not convey. Only the missing usage routing keeps it from being fully self-sufficient.

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

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

Schema description coverage is 0% for the single parameter, so the description carries the burden and adds only 'owned plan', implying planPublicId identifies the caller's own plan. It gives no format, pattern, or lookup guidance beyond that.

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 (Read) and resource (recent native image batches) scoped to an owned plan, and enumerates the outcome states returned. It does not name the sibling it complements (imageGenerationQuote / imageGenerationStart), so the read-vs-create distinction is only inferable from the name.

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 a scope condition ('for an owned plan') but no explicit when-to-use, when-not, or alternative routing against imageGenerationQuote or imageGenerationStart. An agent must infer that this is the polling/inspection tool after starting a batch.

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

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

Annotations declare the mutation/idempotency profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), and the description adds value beyond them by stating 'This does not call an image model or charge credits' and that the quote is 'expiring'. It does not explain the confirmation-capability handshake or what happens when a quote lapses, which the schema only hints at.

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 with no filler, front-loaded with the action and scope, followed by the operational ordering hint and the cost disclaimer. Every sentence earns its place.

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

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

With an output schema present, return-value explanation is unnecessary, and the description covers the key concerns for a quote/preparation step: credit reservation, no model call, no charge, expiry. The main gap is the confirmation/idempotency retry flow, which is only covered inside the schema and not surfaced for the calling agent.

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

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

Schema description coverage is only 22%, so the description must carry more weight. It loosely maps meaning onto expectedVersion ('exact plan version'), referenceAssetIds ('owned reference IDs') and ideaId ('one saved AI image idea'), but says nothing about variationCount, requestId or messageId, leaving several required parameters unexplained in both places.

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

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

The description gives a specific verb and resource ('Prepare a native expiring image quote') scoped to 'one saved AI image idea at the exact plan version and owned reference IDs'. It also explicitly distinguishes itself from the sibling imageGenerationStart by naming it, so an agent can separate the two without opening schemas.

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

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

It states the sequencing rule clearly: show the estimated/maximum credit reservation 'before requesting imageGenerationStart', which names the alternative tool and the condition that leads there. There is no explicit when-not or failure guidance (e.g. what to do if the quote expires), 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?

Annotations already declare destructive=true, idempotent=false, openWorld=true, but the description adds the crucial consequence that this reserves the maximum AI credits and queues jobs, and that image IDs do not constitute publication approval. It omits retry/idempotency semantics even though the schema carries an _idempotencyKey, which is a notable gap for a non-idempotent 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 core action is front-loaded in the first sentence and each subsequent sentence addresses a distinct concern (outcome retrieval, approval boundary, downstream flow). It is slightly dense and blends orchestration guidance with tool scope, but 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?

With an output schema present, return values need not be explained, and the description covers the action, its cost implication, and the approval boundary. It is largely complete, with the only real gap being retry/idempotency behavior for a non-idempotent, credit-consuming 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 only 40%, so the description must compensate. It effectively explains confirmationToken ('exact unexpired image quote token') and implies quotePublicId, but says nothing about requestId, _idempotencyKey, or _confirmationCapability, leaving half the parameters undocumented in both places.

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

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

The description uses a specific verb+resource chain ('Confirm the exact unexpired image quote token, reserve its maximum AI credits and queue native image jobs'), telling the agent exactly what side effects it triggers. It also names the sibling imageGenerationList and clarifies this tool is not it, so the agent can differentiate without opening either schema.

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

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

It routes the agent explicitly to imageGenerationList for outcomes and states that generated IDs do not approve publication, plus the mediaGet-then-reapprove workflow. It lacks an explicit statement of prerequisites for obtaining the quote token (i.e., use imageGenerationQuote first), but the surrounding 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=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond that: missing metrics stay 'unknown rather than zero', reason/nextAction explain missing or stale data, and reconnect_social_account refers to a different product surface. This is meaningful semantic disclosure the annotations cannot express.

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

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

Purpose is front-loaded in the first clause and the paragraph is dense with no filler sentences. It drifts toward response-field semantics later, but each sentence carries information an agent would otherwise have to infer, so 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?

An output schema exists, so explaining return values is technically optional, and the description instead spends its budget on field semantics. That leaves the three input parameters — including the only enum — completely unexplained in both schema and description, which is a real gap for a tool with an optional filter and pagination.

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

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

Schema description coverage is 0%, so the description carries the full burden for kind, limit and cursor — and it says nothing about any of them. The enum values (social, whatsapp), the 1-20 limit bound and cursor pagination are never explained. The paragraph instead documents response fields, leaving the actual inputs undocumented.

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

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

States a specific verb+resource: 'Returns owned Insights accounts' with the scope ('owned') and enumerates what accompanies them (channel totals, reporting periods, freshness). An agent can distinguish it from insightsPostList (posts) and insightsRefresh (refresh action). It stops short of naming those siblings explicitly, so it is clear but not fully differentiated.

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

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

There is no when-to-use guidance and no routing against the close siblings insightsPostList and insightsRefresh. The only directional statement is the reconnect_social_account clarification, which tells the agent where NOT to reconnect, but it does not say when this tool is the right choice over the alternatives.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them with data-quality disclosure: results are cached, undated readings are included by default, the account reason/nextAction/lastCheck explain empty or stale results, and missing metrics stay unknown. These caveats materially change how an agent should interpret and report the response.

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 sentences, no filler, with the return contents front-loaded before the caveats. Sentences are long and densely packed, but each one carries distinct information rather than repeating the schema or annotations.

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

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

With an output schema present, the description need not explain return values, and it is unusually complete on result interpretation (caching, empty pages, unknown metrics). The main shortfall is that four of five input parameters remain undefined anywhere, which is a real gap for a tool with a connectionPublicId requirement.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden, but it only explains includeUndated (default true, false excludes undated readings). The other four parameters — connectionPublicId, kind, limit, and cursor — receive no meaning in the description, and the schema itself documents none of them.

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

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

States a specific verb and resource ('Returns paginated cached posts') and enumerates the payload contents (metric breakdowns, reporting windows, captions, timestamps), which is far more than a restatement of the title. It does not name or distinguish itself from nearby siblings like insightsAccountList or insightsRefresh, leaving that inference to the agent.

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

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

Usage is implied by the framing ('cached posts', 'readings'), and the description does give interpretive guidance for empty results ('an empty page alone does not prove there are no posts'). However, it never states when to prefer this tool over insightsAccountList or insightsRefresh, nor any prerequisite for calling 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 (readOnly=false, destructive=true, idempotent=false, openWorld=true) set the safety profile, and the description meaningfully adds that the operation is queued/asynchronous and performs no publishing or channel selection. It stops short of stating what gets overwritten or the confirmation/idempotency flow the schema hints at.

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

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

Three sentences, front-loaded with the core action, then two tightening constraints (async nature, no publishing/channel selection). Dense but each sentence carries weight; minor verbosity in the Slack/Mattermost/Teams clause.

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

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

For a destructive, non-idempotent mutation with a confirmation-capability protocol and only 40% schema coverage, the description covers the async/queue semantics but omits the confirmation and idempotency behavior. Output schema exists, so return values need not be explained.

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

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

Schema coverage is only 40% and the description adds no information about any of the 5 parameters (kind, templatePublicId, connectionPublicId). With descriptors missing for the connection/template identifiers, the description does not compensate for the coverage gap.

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

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

States a specific verb and resource: 'Queues a bounded provider feed refresh that updates cached post and available account Insights.' This clearly distinguishes it from read-style siblings like insightsPostList/insightsAccountList, though it doesn't name a sibling directly.

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

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

The description implies this is the action to refresh stale cached Insights, but never states explicitly when to call it versus the list tools or any prerequisites. The 'queued result is not a completed refresh' note helps set expectations but is behavioral rather than alternative-routing guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the nature of the payload (publishing rules, media and text limits, required settings), which helps an agent judge relevance, but says nothing about auth requirements, caching, or freshness of the limits. With annotations carrying the behavioral burden, a 3 is appropriate.

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

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

A single sentence that front-loads the verb and then enumerates the payload with no filler or restatement of the name. Every clause carries information an agent can use.

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

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

An output schema exists, so the description is not obligated to explain return values, and the schema fully documents parameters and their constraints. What is missing is any routing or timing guidance (when this must be called relative to publishing flows), which is the only material gap for a low-complexity 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 description coverage is 100%, so all three parameters (platform, isPremium, connectionId) are already documented, including the fact that isPremium is deprecated and that limits come from the selected account. The description adds no parameter-level meaning beyond that, which is the baseline expectation when the schema does the heavy lifting.

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

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

The description states a specific verb and resource ('Returns native platform publishing rules, image and video limits, maximum text length and required settings'), which is far more informative than the title alone. It does not, however, name or contrast itself with near-neighbours such as redditSubredditRequirementsGet or tiktokCreatorInfoGet, so sibling differentiation is left to inference.

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

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

There is no explicit when-to-use statement, but the enumerated return content (limits, required settings) strongly implies the tool is for validating content against platform constraints before composing or publishing. No prerequisites, exclusions, or alternatives are given, so usage remains 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 real value beyond that: authentication prerequisites (owned active account), a provider-availability caveat, and a stability constraint that the connection and search fields must be held constant across cursor pages.

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 with no filler; the core purpose is front-loaded and the constraint and pagination sentences each carry distinct, necessary information. Nothing is repeated and 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 an output schema present, the description need not explain return values, and it covers prerequisites plus pagination mechanics adequately. Minor gaps remain (what happens with zero matches, whether the search is exact or fuzzy), but nothing essential to invoking it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3 and the schema already documents connectionId, q, and cursor in detail. The description only reinforces the nonempty q rule and the cursor continuation protocol, adding no format, length, or provenance detail beyond the schema.

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

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

States a specific verb and resource ('Find a destination community') scoped by 'nonempty search text', which is enough for an agent to know it is a discovery/lookup tool. It does not explicitly name the Lemmy platform or contrast itself with parallel siblings like redditSubredditSearch or wrapcastChannelSearch, so it stops short of the 5 level.

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

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

Provides clear operating context: an owned active account and current provider availability are required, and it prescribes the pagination workflow ('Follow nextCursor until done, keeping the same connection and search fields'). No alternative tools or when-not-to-use conditions are named, so it lacks the explicit routing a 5 would require.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real behavioral context: an account/provider availability gate that can make the call fail, plus the requirement to stay on the same connection while paging. This goes meaningfully beyond what the annotations state.

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

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

Three short sentences, zero padding, with the core purpose and pagination protocol front-loaded before the prerequisites. Nothing here 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?

Preconditions, pagination, and cursor-stability are all covered, and an output schema exists so return values need not be described. The only blemish is the reference to "search fields" despite no search parameter in the schema, which could momentarily mislead an agent constructing the 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 both parameters are already documented; the schema itself says cursor must come from a previous page of this exact tool and input. The description's "keeping the same connection and search fields" largely restates that, with the extra wrinkle that no search parameter actually exists 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?

Specific verb+resource ("List available subscriber lists") with a clear scope, and the name identifies Listmonk. It does not differentiate from the sibling listmonkTemplateList or other *List tools, so an agent must infer the distinction.

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 preconditions (owned active account, provider availability) and a pagination protocol (follow nextCursor until done), which is genuinely useful usage guidance. However, it never says when to prefer this over alternatives such as listmonkTemplateList or when not to call it, so 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 establish that this is a read-only, idempotent, non-destructive operation. The description adds useful behavioral context beyond the annotations by disclosing account/provider prerequisites and the need to preserve connection and search context while paginating.

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, brief, and structured into three purposeful sentences covering purpose, prerequisites, and pagination. There is 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?

An output schema exists, so the description does not need to explain return values. It covers the key operational constraints and pagination behavior, though it could be slightly clearer about the exact fields that must remain unchanged across pages.

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 both parameters in detail. The description reinforces pagination semantics for the cursor and connectionId, but the reference to keeping 'search fields' is confusing because no search parameter exists in the input 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: 'List available campaign templates.' It is clear enough to distinguish this Listmonk template listing from sibling list operations, but it does not explicitly name the provider or contrast it with alternatives such as whatsappTemplateList.

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 provides prerequisites ('owned active account' and 'current provider availability') and pagination guidance, but it does not state when to use this tool versus sibling alternatives or when not to use it. Usage is implied rather than explicitly routed.

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 the safety profile is covered. The description adds genuinely useful operational context beyond that: preconditions (owned active account, provider availability) and an explicit pagination loop ("Follow nextCursor until done, keeping the same connection and search fields").

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

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

Three short sentences, front-loaded with what the tool returns before the prerequisites and pagination instruction. No filler, though the trailing "search fields" clause introduces a term the schema doesn't define.

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

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

With an output schema present, return values need not be described, and the description covers the key gaps an agent has: account preconditions and how to terminate pagination. Complete enough to call correctly, missing only sibling routing guidance.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by telling the agent to reuse the same connection and input fields across pages, reinforcing the cursor contract beyond the schema's per-field note. The mention of "search fields" is slightly confusing since no search parameter exists 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?

Specific verb+resource ("List joined channels") with a clear scope qualifier ("available to this publishing account"), so an agent can distinguish it from siblings like slackChannelList or discordChannelList. It never explicitly contrasts itself with those siblings, so it stops short of a 5.

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

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

It states prerequisites ("Requires an owned active account and current provider availability") and a pagination procedure, which implies when the tool is callable. However it never names an alternative provider's channel list or explains when to prefer this over slackChannelList/teamsChannelList, so usage is only partially guided.

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

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

Despite annotations already declaring a safe read (readOnlyHint, idempotentHint, destructiveHint=false), the description adds substantial behavior: a 6 MiB inline-pixel ceiling, format-dependent byte delivery, 20 MiB image and 5 GB MP4 limits, a five-minute previewUrl lifetime, and the fact that reading grants no publication approval.

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 layered limits and caveats, with every sentence carrying distinct information. Some sentences are dense (format and size limits packed together), which slightly hurts scannability but wastes nothing.

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

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

For a one-parameter read tool with an output schema, the description covers everything an agent needs: what comes back (bytes vs metadata), format/size boundaries, preview expiry, and the approval caveat. Nothing material is missing.

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

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

Schema description coverage is 0% for the single assetId parameter, and the description never mentions it directly. The phrase 'owned ready' media does imply what kind of id is expected, but no format or acquisition guidance compensates for the coverage gap; an adequate-but-thin 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?

States a specific verb and resource with scope: 'Returns one owned ready image or MP4'. The qualifiers 'one', 'owned', and 'ready' differentiate it from mediaList (enumeration) and mediaImport/mediaUpload* (ingestion) without needing to open their schemas.

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

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

Usage is implied through conditions: request mediaGet again when previewUrl expires, and expect metadata instead of bytes for larger or unsupported formats. However, it never states when to choose this over mediaList, mediaImport, or mediaUploadGet, and gives no explicit 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 cover the safety profile (non-destructive, open-world), so the description correctly focuses on what annotations cannot express: retry identity semantics, the ready-vs-pollable asymmetry of the response, and the fact that assetId is only present when ready. It does not spell out authorization requirements despite saying 'authorized', which keeps it from 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?

Front-loaded with the action and then layered constraints, sizes, alternative, and return shape in a tight block with no filler. It is dense — five clauses of limits in two sentences — but each sentence carries distinct decision-relevant information.

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

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

For a 7-parameter tool with nested objects, a confirmation/idempotency protocol, and an output schema, the description covers source modes, limits, retry keys, and return shape. The confirmation capability flow is left entirely to the schema, which is acceptable given the output schema exists and the description need not explain returns.

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

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

Schema coverage is 86%, so the baseline is 3; the description adds real value by explaining that clientKey is an optional stable retry identifier and that the public URL or native file_id serve as the implicit retry key otherwise — semantics the schema leaves undocumented for clientKey.

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 ('Imports an authorized image or video into the workspace library') and enumerates the accepted source modes (public HTTPS URL, native host file, local binary descriptor). It explicitly differentiates itself from the sibling mediaUploadCreate by naming the larger-file case that belongs there.

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?

Routes the agent between the three input modes with size and format constraints for each, and names the alternative tool (mediaUploadCreate) plus the exact condition (larger ready SDR H.264/AAC MP4 up to 5 GB) that should select it. Retry guidance via clientKey vs URL/file_id is also given.

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

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

Annotations already declare read-only, idempotent and non-destructive. The description adds genuinely non-obvious behavior: search or bounded scans may return fewer than 'limit' items and you must continue with cursor until 'done' is true. That goes beyond structured fields.

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

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

Three front-loaded sentences with essentially no waste; the core behavior and pagination caveat come first. Slightly dense phrasing ('ready owned source, edited and converted media') but still earned.

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

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

An output schema exists, so return shape needn't be restated, and the description still references the 'done' flag for completeness. Ordering of results and the meaning of 'ready' remain unstated, a minor gap for a list 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 only 25%, so the description must carry weight. It explains the default behavior of 'kind' when omitted and clarifies that 'cursor' drives a continuation loop and 'search' can under-return, adding meaning beyond the bare schema properties.

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: 'Returns ready owned source, edited and converted media'. It implicitly distinguishes itself from mediaGet/upload tools by noting uploads feed the same library, though it never names a sibling directly.

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

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

Explains filter invocation ('Omitting the filter returns the established JPEG/PNG image list') and pagination continuation, which is useful operator guidance. However, it never states when to prefer this over mediaGet or the scan/search alternatives, leaving selection to inference.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true; the description adds substantive context beyond them: cleanup reuses existing storage handling, completed uploads are untouched, and repeat calls are no-ops. The only gap is error/edge behavior for already-finished uploads.

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 action and scope, with no filler. The idempotency sentence partially restates idempotentHint but adds the 'does not create another operation' 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?

With an output schema present and annotations covering safety/idempotency, the description supplies the remaining essentials: what is destroyed, what survives, and the absence of a confirmation handshake. Only failure-mode behavior on a completed or unknown uploadId is 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?

The single parameter has 0% schema description coverage, so the description must carry the burden and it largely does not. 'Owned upload' hints at an ownership constraint on uploadId, but nothing explains the identifier's format or origin, and the regex/length constraints live only 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?

States a specific verb and resource ('Cancels an unfinished owned upload') and implicitly separates itself from mediaUploadComplete by noting completed uploads are preserved. It never names the sibling tools, so the differentiation is inferential 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?

'Unfinished owned upload' implies the precondition (pending upload you own), and 'No new confirmation is needed' pre-empts a confirmation step. But it never says what to do if the upload is already complete or how to check status (e.g. mediaUploadGet) before cancelling.

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 (non-read-only, idempotent, non-destructive, open-world). The description adds real value beyond them: it enumerates the possible outcomes (uploading, processing, ready, terminal failure), states the attachability precondition (only ready with assetId), and confirms the idempotent replay behavior. It does not detail auth requirements or what a terminal failure means.

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

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

Four tight sentences, front-loaded with the action, then outcomes, then the attachability constraint, then recovery. Every sentence carries distinct, useful information with no padding.

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

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

An output schema exists, so return values need not be exhaustively described, yet the description still names the status states and the assetId attachability rule. It is complete enough for correct invocation, with only parameter-level detail 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 0%, so the description must compensate. It references 'the uploaded parts' and 'the same part manifest,' loosely tying to the parts parameter, but says nothing about uploadId, etag format, or partNumber ranges that the schema only encodes as patterns and bounds. Minimal semantic help for a 2-parameter, 0%-coverage schema.

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

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

States specific verbs and resource: 'Verifies the uploaded parts and starts the existing media preparation.' This clearly places it as the final step in the media upload lifecycle, distinguishing it from mediaUploadCreate, mediaUploadPart, and mediaUploadAbort without naming them. It stops short of explicit sibling differentiation, so not a 5.

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

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

Implies usage (finish an upload once parts exist) and gives one concrete recovery scenario ('Replaying the same part manifest recovers completion'). However, it never states when to call this vs mediaUploadGet, mediaUploadPart, or mediaUploadAbort, 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?

Beyond the annotations (idempotent, openWorld, non-destructive), it discloses critical behavior: 24-hour upload lifetime with renewable URLs, expiring preparations, no file bytes in tool arguments (direct-to-storage transfer with Content-MD5), and per-format size ceilings (20 MiB images, 250 MiB MOV/WebM/M4V, 5 GB MP4, platform limits). This is far more than the annotations convey.

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, front-loaded paragraph where nearly every sentence carries actionable constraint (sizes, expiry, resume, transfer method). It borders on over-packed but avoids filler; a light bullet structure would improve scanability without changing content.

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

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

Despite an output schema existing, the description still frames the return (first batch of signed PUT URLs) and covers the full lifecycle: expiry, renewal, resumption, batching, transfer mechanics, and destination limits. An agent has everything needed to invoke and sequence it correctly.

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

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

With 50% schema coverage, the description meaningfully augments the undocumented parameters: it ties partSizeBytes to the 64 MiB vs 8 MiB tradeoff, explains clientKey reuse for resumption, and maps contentType/sizeBytes to concrete format and size limits. It adds real semantics, though 'name' remains unexplained.

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 action and resource — authorizing an exact file via ordered part checksums and returning signed PUT URLs — which is clearly the 'start/reserve' step of a multi-step upload flow. This distinguishes it from siblings like mediaUploadPart, mediaUploadComplete, and mediaUploadAbort without needing to open their schemas.

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

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

It gives concrete operational guidance: prepare and confirm each file before the next in batches, choose 64 MiB parts for new videos vs the 8 MiB default, call nextPart only when needed, and reuse clientKey/partSizeBytes/checksums to resume. It stops short of naming sibling tools by name, so an agent must infer that 'request nextPart' means mediaUploadPart, 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?

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description still adds useful non-obvious behavior: it never returns write URLs or authorizes an upload, and a converted asset may have a different ID from the uploadId.

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

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

The description is three tight sentences with the core return behavior front-loaded, followed by important exclusions and a caveat. There is no filler and each sentence adds useful information.

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

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

An output schema exists, so the description does not need to fully document return values, and it already names key status fields and the assetId caveat. The main remaining gap is that it does not clarify the relationship between uploadId and the upload-creation 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 schema has only one parameter with 0% description coverage, so the description must compensate. It mentions uploadId only indirectly in the caveat about converted asset IDs and does not explain that uploadId identifies the upload to check or where that ID comes from.

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 read operation and enumerates what it returns: the owned upload, verified uploaded parts, processing status, and final ready assetId. It also distinguishes this status-checking tool from upload mutation tools by stating that it never returns write URLs or authorizes an 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?

Usage is implied by the mention of recovery, processing status, and the final assetId, which suggests checking an upload after creation. The boundary that it never authorizes uploads is helpful, but the description does not explicitly say when to choose this over mediaGet, mediaList, or mediaUploadComplete.

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 this as read-only, idempotent, open-world, and non-destructive. The description adds useful behavioral context: URLs are short-lived, tied to exact part checksums, manifest cannot change, and storage requests need Content-MD5 and not bearer credentials.

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 return behavior is front-loaded and the description is compact. The final sentence is terse but garbled ('never Influence bearer credentials'), which slightly reduces clarity.

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

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

With an output schema and rich annotations present, the description supplies the main operational context: short-lived URLs, paging/renewal, immutable manifest, and request security. Minor ambiguity around nextPart and the garbled credential phrase keeps it from being fully complete.

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

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

Schema coverage is only 33%, so the description should compensate more. It clarifies limit is capped at 32 and startPart can renew expired URLs, but uploadId is only implied via 'owned upload' and the final security instruction is garbled.

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

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

States a specific verb/resource: returns short-lived PUT URLs for authorized upload parts of an owned upload. It is clearly distinguishable from generic media upload tools, though it does not explicitly name sibling alternatives beyond paging 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?

Gives concrete guidance: use nextPart for later pages, startPart to renew expired URLs, and no new confirmation is needed. It lacks explicit when-not-to-use guidance or direct sibling comparisons, but the key operational context is present.

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

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

Annotations already declare a safe, idempotent, non-destructive read, so the bar is lower. The description adds real context beyond them: the owned-account and provider-availability preconditions and the pagination contract of following nextCursor while holding the connection fixed. Minor accuracy issue: it references 'search fields' although the schema exposes no search parameters (additionalProperties=false).

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

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

Three short sentences with the action front-loaded and the pagination instruction last. Nearly every clause earns its place, though 'and search fields' refers to inputs this tool does not have, which is wasted and mildly confusing.

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

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

An output schema exists, so return values need no explanation, and the description covers preconditions and the pagination loop. The only gap is the dangling reference to 'search fields' and the lack of any hint about volume or filtering limits on the result set.

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 cursor and connectionId are already documented, establishing the baseline of 3. The description reinforces cursor semantics ('Follow nextCursor until done, keeping the same connection'), which adds a small amount of meaning but no format or provenance detail beyond the schema.

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

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

States a specific verb and resource: 'List available publishing groups.' An agent immediately knows this enumerates MeWe publishing destinations, and the MeWe-specific naming plus the sibling list of per-platform *List tools makes the target platform unambiguous.

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

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

The description gives prerequisites ('Requires an owned active account and current provider availability') but never states when to choose this tool over alternatives or what condition selects it. Usage is only implied by the tool name and the prerequisite sentence.

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 behavior, so the safety profile is covered. The description adds value beyond that with prerequisite conditions and the pagination invariant (reuse connection and search fields), which an agent would not otherwise know.

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

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

Three short sentences: purpose first, then prerequisites, then iteration guidance. No filler, and the operation's core meaning is front-loaded.

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

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

With annotations, a full output schema, and 100% schema coverage, the description only needs to supply prerequisites and pagination behavior, both of which it provides. Nothing critical seems missing for correct invocation, though return-shape context is left entirely to the output schema.

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

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

Schema coverage is 100%, so both parameters are already documented, and an output schema exists. The description's 'Follow nextCursor until done' reinforces how the cursor param is used but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('List available publishing boards'), which is enough to identify the operation clearly. It does not explicitly name Pinterest or contrast with a sibling, but no sibling is directly confusable with this resource, so the purpose reads cleanly 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 prerequisites ('owned active account and current provider availability') and operational guidance for iteration ('Follow nextCursor until done, keeping the same connection and search fields'). It does not name an alternative tool or when-not-to-use, 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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the profile ID is stable across refresh, reconnect, and display-name changes, and it clarifies that 'nickname' carries the workspace display name. That is useful beyond the annotations, though it says nothing about auth requirements or failure modes.

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, front-loaded with what the caller actually receives. The second sentence about ID stability is a discrete, non-redundant fact rather than padding.

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

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

With an output schema present, the description need not enumerate return values, and with rich annotations the safety behavior is covered; adding the ID-stability guarantee fills the one behavioral gap an agent would plausibly care about. The only shortfall is the absence of any usage/routing context relative to sibling account-reading tools.

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 and the baseline is 4. The field-level naming it does provide ('nickname' = workspace display name) concerns the response shape rather than inputs.

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

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

States a specific verb+resource combination ('returns the authorized account email and display name, workspace display name, opaque workspace profile ID') for the connected profile, which is distinguishable from generic siblings like accountList. However, it does not name or contrast against any sibling that could plausibly be confused with it, which keeps it below a 5.

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

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

The description contains no when-to-use guidance, no prerequisites, and no mention of alternatives such as accountList or connectionStatusGet. An agent must infer that this is the identity lookup, which is reasonably obvious for a zero-argument getter but is not stated anywhere.

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

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

Annotations already declare the safe read profile (readOnly, idempotent, non-destructive, openWorld), and the description adds value beyond them: the account-ownership and provider-availability preconditions plus the requirement to keep the same connection and search fields across pages. Pagination stop condition ("until done") is also 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?

Three short sentences with no waste: what it does, what it needs, how to page through it. The core action is front-loaded and nothing is repeated.

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

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

An output schema exists, so return values need no explanation. With annotations covering safety, the schema covering all three parameters, and the description covering prerequisites and pagination, an agent has everything needed to call this correctly.

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

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

Schema description coverage is 100%, so connectionId, subreddit and cursor are all documented at the source; the baseline is 3. The description's cursor guidance largely restates the schema's "nextCursor from the previous page of this exact tool and input", adding only marginal operational framing.

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 ("Read the selected subreddit's publishing requirements") with an implicit scope marker ("selected") that ties it to the search step. It is distinguishable from redditSubredditSearch, but the sibling is never named explicitly, so the differentiation is inferential 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?

Gives concrete preconditions (owned active account, current provider availability) and a usage rule for completeness (paginate with nextCursor). It stops short of naming when to prefer this over redditSubredditSearch or any other sibling, so no explicit alternatives 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 declare readOnly, idempotent, open-world, non-destructive. The description adds valuable behavior beyond them: the auth prerequisite (owned active account), transient provider availability, and the pagination contract (same connection and search fields). It does not disclose rate limits or result shape, keeping it below 5.

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

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

Three short sentences, front-loaded with the purpose, then prerequisites, then pagination. Every sentence carries information with no filler, though it is terse rather than maximally structured.

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

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

An output schema exists, so return values need not be explained. The description covers the two things an agent most needs here: auth prerequisites and cursor pagination semantics. It is nearly complete, missing only explicit sibling routing.

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 all three parameters (word, cursor, connectionId) are already documented in the schema. The description references 'nextCursor' and 'search fields' but adds no syntax or format detail beyond what the schema provides, so the baseline of 3 applies.

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

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

The description states a clear verb+resource: 'Find a destination subreddit.' An agent can tell this searches subreddits, distinct from redditSubredditRequirementsGet. However, it does not explicitly name the sibling or contrast its scope, so it stops short of a 5.

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

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

It gives prerequisites (owned active account, provider availability) and pagination guidance (follow nextCursor with the same connection and fields), which is real usage context. But it never says when to choose this over alternatives such as redditSubredditRequirementsGet, leaving tool selection to inference.

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