ClipEmber

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds a genuine state-machine constraint (posts already published are un-cancelable) that isn't in any structured field, which is useful behavioral context beyond the annotations.

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

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

Two sentences, zero waste, with the eligibility scope front-loaded and the exclusion rule immediately following. Every sentence earns its place.

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

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

For a single-parameter mutation with no output schema and annotations covering the safety profile, the description is close to sufficient: it states eligibility and the exclusion rule. The main gap is how to obtain the postId.

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 burden, yet it never names or explains postId. It only implies the argument refers to a post via 'a queued or failed post,' leaving format, source, and lookup unaddressed.

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 (remove/cancel) and resource (queued or failed scheduled post) and scopes eligibility ('queued or failed'). This implicitly distinguishes it from siblings like retry_failed_post and reschedule_post, though no sibling is named explicitly.

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

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

It gives a clear 'when not' condition ('a post that already went out cannot be canceled') but offers no alternative routing (e.g., use retry_failed_post vs. this tool). Usage 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 only declare readOnly=false, openWorld=true, idempotent=false, destructive=false. The description adds substantial non-derivable behavior: credit consumption, immediate return with a requestId, a ~5 minute typical pipeline with a 1-in-10 tail of 15+ minutes, and the anti-polling constraint. None of this is available from structured fields.

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

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

Front-loaded with the action and cost, then latency, then follow-up protocol. Every sentence carries operational information (cost, timing, tool routing, poll interval, turn boundary) 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?

For an async job-creating tool with no output schema, it covers the essentials: what is charged, what is returned (requestId), how long it takes, and exactly how to retrieve results. An agent has everything needed to invoke it without guessing.

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 89%, so the schema already documents start, end, series, teaser, language, watermark, noClipping, and preferredLength in detail. The description only restates the 'url' source types, which the schema also states verbatim, so it adds little for the 9 parameters. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Start a new AI clipping job') plus the accepted input source forms ('YouTube (or direct video file) URL'). It is clearly distinguishable from siblings like clipember_get_clip_request, clipember_list_clip_requests, and clipember_schedule_series.

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

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

Gives explicit preconditions (check clipember_get_credit_balance first, costs 1 credit), the correct follow-up tool (clipember_get_clip_request), a concrete polling cadence ('no more than once every 30-60 seconds'), and a workflow rule to continue in a later turn rather than blocking. This is when-and-how guidance an agent can act on directly.

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

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

Annotations only cover the generic safety profile (readOnly=false, destructive=false, openWorld=true, idempotent=false). The description adds genuinely non-derivable behavior: YouTube Shorts/Instagram Reels post publicly and irreversibly, TikTok only uploads and requires an in-app Inbox notification step by the user, and the account must already be connected. That is exactly the context an agent cannot get from structured fields.

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

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

The the critical public-posting warning is front-loaded right after the purpose sentence, and every sentence carries actionable content. It is on the long side (five sentences, including the TikTok notification walkthrough), but that length is driven by real platform divergence rather than filler.

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

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

For a mutation tool with no output schema, the description covers the hazards, prerequisites, and per-platform outcomes well. What it omits is failure/duplicate handling — with idempotentHint=false, an agent isn't told whether a retry or repeated call double-posts, and no return value (e.g., a scheduled post id) is hinted at.

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

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

Schema coverage is low (33%), with only scheduledFor documented in the schema. The description compensates well: it explains scheduledFor semantics ('right now or a few seconds out' means act immediately) and gives rich meaning to the platform enum values. clipId remains unexplained beyond the implied 'rendered clip', which is the one gap preventing a 5.

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

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

The first sentence states a specific verb (queue), resource (rendered clip), and effect (publish to a platform at a given time). It is immediately distinguishable from siblings like clipember_reschedule_post, clipember_retry_failed_post, and clipember_create_clip_request.

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

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

It gives explicit when-to-use guidance (confirm with the user before public YouTube/Instagram posting), an alternative pattern (pass scheduledFor of right now to act immediately), and a prerequisite with the exact sibling to check (platform must be connected — clipember_list_platform_connections). Per-platform behavioral branching is spelled out rather than 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 only tell the agent this is a non-read-only, non-idempotent, open-world, non-destructive call; the description adds the materially important consequence that approving publishes publicly and that edits (caption/platforms) must happen before approval. It omits permission/auth requirements and confirmation that repeated calls with the same proposalId fail, so it stops short of full disclosure.

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

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

Three tight sentences, front-loaded with the verb pair and the irreversible public-publish consequence immediately after. Every clause carries decision-relevant information with no filler.

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

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

For a 7-parameter, nested-object mutation tool with no output schema and only 57% schema coverage, the description covers the main approve/reject flows and the public-publish side effect well. It is still silent on the scheduledFor and reasonNote overrides and on what a successful decision returns, which leaves minor gaps for an agent handling approval-with-edits.

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 57%, and the description adds useful intent for caption (override before approving) and platforms (add/change before approving) plus the learning-loop role of the reject reason. It never explains scheduledFor (publish-time override) or reasonNote, leaving two parameters entirely to the schema.

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

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

States a specific verb pair (approve/reject) and a specific resource (pending Autopilot post proposal), and names clipember_list_autopilot_proposals as the source, which distinguishes it from the other 29 siblings. An agent can tell immediately this is the decision endpoint for proposals rather than a creation or scheduling tool.

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

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

Gives clear context for both branches: approving schedules a public publish, rejecting removes from the queue. It does not, however, say when an agent should reject versus escalate, or when to use this instead of clipember_create_scheduled_post / clipember_cancel_scheduled_post for the same content, so the alternative-routing is left implicit.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is known. The description nonetheless adds concrete value by specifying the blast radius (the parent entity and all rendered clips plus their underlying files) and reinforcing irreversibility. It stops short of saying what happens to in-flight renders or whether auth elevation is required.

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 destructive verb front-loaded and the irreversibility statement closing. There is no padding or repetition of the title.

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

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

For a single-parameter destructive tool with no output schema, annotations cover safety and the description covers destruction extent, so the core is adequate. What is missing is disambiguation of the target entity ('project' vs 'clip request') and any note on what happens to an active render job, which is material for an irreversible operation with no undo sibling.

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

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

Schema description coverage is 0% and the description never mentions the single requestId parameter, what it identifies, or accepted format. It also does not clarify whether the UUID refers to a clip request or a clip, which matters because the description's noun ('project') differs from the parameter name. With no compensating text, an agent must infer everything from the parameter name alone.

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

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

The verb and scope are specific ('Permanently delete... all its rendered clips (and their files)'), which goes beyond the title. However, the description calls the target a 'project' while the name, title, and sibling tools (get_clip_request, rename_clip_request, list_clip_requests) establish the resource as a 'clip request'. That noun mismatch leaves the agent unsure whether 'project' is a synonym or a different entity whose clips are being deleted.

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

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

No when-to-use guidance, no prerequisites, and no alternatives are named. Given siblings like rename_clip_request and cancel_scheduled_post, an agent gets no help deciding whether deleting is the right action versus renaming or cancelling. Only the implicit 'this destroys things, be careful' framing 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 readOnlyHint/idempotentHint/destructiveHint=false, and the description's trailing 'Read-only' merely restates that. Its only added value is the field list (name, email, billing plan), which is real content but not behavioral context about auth, failure modes, or when settings are 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 short sentences with the resource and returned fields front-loaded and no filler. The only minor redundancy is the 'Read-only' clause, which repeats the annotations, but it costs almost 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 parameterless read tool with no output schema, the description does the necessary work by naming the returned fields, which is what the output schema would otherwise supply. It omits edge behavior (no connected account, plan unknown), keeping it just short of 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?

The tool takes zero parameters, so the schema carries nothing to interpret and the description has no parameter semantics to add. Baseline 4 applies; nothing is misdescribed or missing on this dimension.

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 (get the connected ClipEmber account's) and enumerates the returned fields (name, email, current billing plan), so the agent knows what it retrieves. It does not, however, distinguish itself from adjacent read siblings like get_subscription_status or get_credit_balance, whose scope partially overlaps with 'billing plan'.

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

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

No when-to-use guidance, no exclusions, and no mention of alternatives such as get_subscription_status or get_credit_balance. Usage is only weakly implied by the resource name, which leaves the agent to infer whether billing plan data belongs here or in a sibling call.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description's only added behavioral context is the 7/30-day window constraint; it says nothing about granularity, per-platform breakdown, or aggregation of the returned KPIs.

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 that front-loads the resource and the returned metrics with no wasted words. Nothing could be trimmed without losing information.

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

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

For a one-parameter, read-only analytics tool with no output schema, the description says enough to call it correctly and sets expectations for what comes back. It leaves minor gaps such as whether KPIs are broken down by platform or time bucket.

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 burden, and it does restate the allowable window ('7 or 30 days'). However, the schema already encodes these exact values via const 7/30 and default 7, so the description adds confirmation rather than new meaning.

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

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

States a specific verb (Get) and resource (Autopilot analytics), and enumerates the concrete KPIs returned (views, posts, top performers). No sibling in the list is an analytics tool, so confusion risk is low, but the description never explicitly distinguishes itself from the list_autopilot_* siblings.

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

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

The time window ('last 7 or 30 days') frames the scope, so the intended usage is implied, but there is no explicit when-to-use guidance, prerequisites, or routing to an alternative sibling.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is fully covered and the bar is low. The description still adds real value beyond them by disclosing the shape of the response and the conditional behavior that the download link only exists "if rendered".

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 zero filler; the most decision-relevant fact (it returns one clip) leads, and the returned fields follow compactly.

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

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

With no output schema, the description usefully enumerates the returned fields and the conditional download link, which is exactly the burden it must carry. What is missing is any routing guidance relative to clipember_list_clips and clipember_get_clip_request, plus any hint about the clipId argument.

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 is the only place parameter meaning could be added, and it says nothing about clipId. The only hints (uuid type/pattern) come from the schema itself, which the description does not supplement with format, source, or lookup guidance.

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

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

States a specific verb+resource ("Get a single clip's details") and enumerates the fields returned (score, hook, status, download link). The word "single" implicitly separates it from clipember_list_clips, but no sibling is named explicitly, 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?

Usage is only implied: a reasonable agent infers this is for fetching one clip when a clipId is known, versus clipember_list_clips for enumeration. There is no explicit when-to-use, when-not-to-use, or named alternative, and no mention of where a clipId comes from.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description adds meaningful behavioral context beyond that: this is an asynchronous, staged operation you poll, and results only materialize "once done" as rendered clips with scores and download links. It stops short of polling cadence or terminal-state guidance.

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

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

A single front-loaded sentence that packs the verb, resource, origin link, and return content without filler. Every clause earns its place.

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

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

With no output schema, the description usefully characterizes the return value (stage progress, then clips with scores and links), and annotations cover safety. It is nearly complete for a 1-param read tool, though polling behavior and terminal/error states are left implicit.

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

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

Schema coverage is 0% – requestId has only a uuid pattern and no prose description. The description partially compensates by implying requestId is the identifier returned by clipember_create_clip_request, but it adds no format or sourcing detail beyond that link.

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

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

States a specific verb (poll/get) and resource (a clip request's status, including stage progress and rendered clips). It ties the resource to its origin tool (clipember_create_clip_request), making the intent unambiguous. It does not explicitly contrast with close siblings like list_clip_requests or get_clip, 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?

"Poll a clip request created by clipember_create_clip_request" gives clear context: use after creating a request to track its progress. It implies repeated polling usage but names no exclusions or alternatives (e.g., list_clip_requests for enumeration, delete for cleanup).

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 non-destructive. The description adds the business rule that each clip request spends 1 credit, which is useful context beyond annotations. However, no rate limit or return-format detail is provided.

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 waste; the parenthetical cost note is concise and additive.

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?

Complete for a zero-parameter read tool whose annotations carry the safety profile. The only minor gap is no mention of what the balance represents at zero or format of return, but that is minor.

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

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

The tool has zero parameters, which sets the baseline at 4. The parenthetical explaining credit consumption adds meaning without overcomplicating.

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

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

States a specific verb (Get) and resource (the account's current credit balance), clearly distinct from siblings like list_credit_usage or get_subscription_status. The parenthetical quantifying the cost unit makes the resource concrete.

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?

Implied usage as a simple read of current balance, but offers no when-to-use guidance or alternatives such as list_credit_usage versus this balance check. No exclusions or prerequisites 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?

The annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real content beyond them by enumerating what the response contains (code, link, invites, signups, credits earned), which matters since there is no output 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?

One sentence with no filler, front-loaded with the verb and the returned resource, and the parenthetical list is efficient rather than 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?

For a 0-param read tool with no output schema, the description covers what the agent needs to know about the return contents. It stops short of describing the shape of the stats object, but nothing essential to invoking it is missing.

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

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

The tool takes zero parameters, so per the baseline there is nothing for the description to clarify. No parameter-level ambiguity is introduced.

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

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

States a specific verb ('Get') and resource ('the account's referral code, shareable link, and referral stats'), so the agent knows exactly what comes back. It does not name or contrast with siblings like get_credit_balance or get_account_settings, which is the only thing keeping it from a 5.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no named alternative, but for a zero-parameter read tool the intent is strongly implied by the description of the returned referral data. Adequate rather than instructive.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds the dashboard/chat constraint but doesn't mention return format, whether history is paginated, or how recent 'recent' is.

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; the core purpose is front-loaded and the dashboard boundary follows with no wasted words.

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

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

For a no-param, read-only tool with no output schema, the description covers purpose and the key limitation. It could say slightly more about what 'recent payment history' contains, but nothing critical is missing.

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

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

Zero parameters, so baseline is 4. The description correctly implies no inputs are needed to retrieve the account's plan and payment history.

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 ('Get the account's current plan and recent payment history') and distinguishes from siblings like clipember_get_account_settings and clipember_get_credit_balance by naming plan and payment content 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?

Adds a clear usage boundary: 'Changing plans happens in the dashboard, not via chat,' which signals when this tool is read-only and excludes an adjacent intent. No alternative tool is named for related billing questions, but the context is clear.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds genuinely new behavioral context: the full secret is never returned and is only visible once at creation. That is exactly the kind of non-obvious disclosure annotations cannot carry. It stops short of describing pagination or result ordering.

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

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

Two short sentences, front-loaded with the action and the returned fields, followed immediately by the most important caveat about the secret. No filler.

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

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

For a parameterless read tool with full annotation coverage, the description supplies everything needed: what it returns and the critical limitation that secrets are unavailable. The absence of an output schema is mitigated by the explicit field enumeration.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to clarify, and it correctly does not invent parameter semantics.

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

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

States a specific verb and resource ("List the account's API keys") and even enumerates the returned fields (name, prefix, last used), so the agent knows exactly what this yields. It does not explicitly name the sibling clipember_revoke_api_key, but the list-vs-revoke distinction is obvious from the verb.

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

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

Usage is implied by the purpose — call this to enumerate the account's keys — but there is no explicit when-to-use, when-not-to-use, or reference to alternatives such as clipember_revoke_api_key. Adequate but leaves routing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavioral content by disclosing what the response contains ('pending-review and shortlist counts'), which matters because there is no output 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?

A single dense sentence that front-loads the action and resource, then qualifies the resource and previews the return payload. Every clause earns its place with no filler.

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

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

For a no-parameter, annotation-covered read tool with no output schema, the description covers purpose, scope and the key return fields. Only the precise shape of the result (per-automation fields, ordering, pagination) is left unspecified, which is a minor 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?

The tool takes zero parameters, so the baseline is 4. There is nothing parameter-related the description could add, and it does not confuse the reader with phantom 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?

Specific verb (List) plus resource (Autopilot automations), and the parenthetical 'channel-watch/search configs' clarifies what an automation actually is, distinguishing it from the sibling proposal and source listing tools. It stops short of naming those siblings explicitly, so differentiation is implicit 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?

Usage is implied by the name and the parenthetical scope ('channel-watch/search configs'), which is adequate for a zero-parameter listing tool. However, there is no explicit when-to-use vs. when-not guidance and no mention of the related clipember_list_autopilot_proposals / clipember_list_autopilot_sources siblings an agent might confuse it with.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuine value beyond that by disclosing the default filter scope (pending proposals awaiting review) and the sort order ('deadline soonest first'), neither of which is in the structured fields.

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

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

A single tight sentence that front-loads the resource and default scope, then appends the filter and ordering caveats. No filler.

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

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

For a simple read-only list tool with rich annotations but no output schema, the description conveys what is returned, the default scope, and the ordering. Pagination via limit is implied but not elaborated, a minor gap given the low complexity.

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

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

Schema description coverage is 0%, so the description must carry the burden. It explains the decision filter's effect ('or already decided, if filtered') but says nothing about the limit parameter or its pagination role, leaving half the parameters 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 (List) and resource (Autopilot's queued post proposals), and clarifies the review state of the items. It doesn't explicitly name the read-vs-decide distinction against the sibling clipember_decide_autopilot_proposal, so it falls short of full differentiation.

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 parenthetical '(or already decided, if filtered)' implies you can broaden the result set via the decision filter, but there's no explicit when-to-use-this-vs-alternatives guidance, and the relationship to clipember_decide_autopilot_proposal (the acting counterpart) is left unstated.

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 full safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds genuine value by disclosing what is returned – source types plus their rights-attestation status – which is not derivable from annotations or schema. It omits pagination/ordering 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; the resource is named first and the returned data is appended as a qualifier. Every clause earns its place.

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

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

There is no output schema, so the description must characterize the return value – and it does, naming the sources and the rights-attestation status field. Combined with annotations that cover the safety profile and a single simple parameter, this is sufficient for an agent to call the tool correctly.

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

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

One required parameter with 0% schema description coverage, so the description carries some burden. 'A given Autopilot automation' implies the automationId's role, but the description never states the expected identifier format (UUID) or where to source it (e.g., from list_autopilot_automations).

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') plus the exact resource ('video sources ... feeding a given Autopilot automation') and enumerates the source kinds (YouTube channel/search/manual list). This clearly distinguishes it from siblings like clipember_list_autopilot_automations and clipember_list_autopilot_proposals.

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 scoping phrase 'feeding a given Autopilot automation' – an agent can infer this is the tool for inspecting what feeds one automation. However, there is no explicit when-to-use guidance, no mention of how to obtain the automationId, and no exclusions or alternatives 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 readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuine context beyond that: the semantic role of the assets (per-caption enrichment in the editor) and the fact that creation requires a presigned upload outside chat, which preempts a mistaken attempt to mutate the collection.

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

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

Two tight sentences with no filler, and the core identity of the tool is front-loaded before the caveat about uploading. Every clause carries information.

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

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

For a zero-argument, fully-annotated read-only listing tool with no output schema, the description supplies what an agent needs: what is listed, what it is for, and the one adjacent action that is unavailable. It stops short of noting return shape or pagination, which is acceptable given the absence of an output schema.

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

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

The tool takes zero parameters, so there are no parameter semantics to document and the baseline is 4. The description correctly does not invent parameter 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 ('List the account's uploaded B-roll clips') and scopes it to the account. The parenthetical explaining B-roll is used for per-caption enrichment disambiguates it from the many other list_* siblings (list_clips, list_clip_requests), though it never explicitly names the closest alternative.

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

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

It tells the agent what is NOT possible ('uploading ... isn't available via chat'), which usefully prevents a dead-end call, but gives no positive guidance on when to reach for this versus clipember_list_clips or other listing tools. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, covering the safety profile. The description adds useful value by stating ordering (newest first) and the returned fields (status, top clip score), which go beyond the annotations.

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

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

One compact sentence that front-loads the action, resource, ordering, and key output fields. No waste.

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 and return highlights, but with 0% schema coverage and no output schema, it omits parameter meaning (limit) and any pagination behavior, leaving gaps 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 0%, so the single 'limit' parameter (with default 20, max 50, min 1) is undocumented in the description. With one parameter the baseline is 4, but the description provides no semantics for limit at all, leaving it slightly penalized.

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 (past clip requests, clarified as projects), and notes ordering (newest first). It does distinguish itself from clipember_get_clip_request (singular) by being the list variant, though it doesn't explicitly articulate that 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?

No guidance on when to use this list tool versus get_clip_request, list_clips, or other retrieval siblings. The agent must infer usage purely 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds one useful behavioral detail — that the search is global across all projects, not scoped to one — but says nothing about result limits, pagination, ordering, or case sensitivity, and there is no output schema to fill those gaps.

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 with zero filler. The matching scope (title/hook), the constraint, and the account-wide scope are all front-loaded in one pass.

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 search tool with rich annotations, the core is present. However, with no output schema, the description should say something about what the search returns — ordering, result caps, or whether matches are fuzzy or exact — and it is silent on all of these.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does add real meaning: the query matches only title/hook text (not transcripts or notes) and is limited to 2-100 chars. The length constraint duplicates the schema's min/maxLength, but the 'title/hook' matching semantics are genuinely informative beyond the schema.

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

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

The description gives a specific verb (full-text search), a resource (the account's clips), and the matched fields (title/hook), plus the scope 'across all projects'. It is clearly distinguishable from clipember_get_clip (single fetch) and clipember_search_youtube (different resource), though it never explicitly names a sibling to contrast against.

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

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

Usage is only implied: an agent can infer this is the keyword-search entry point for clips, but the description gives no when-to-use vs when-not guidance and no mention of alternatives such as listing clip requests or fetching a single clip. The 'across all projects' phrase hints at broad-scope use but doesn't route the agent.

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, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the hard 100-entry result cap and descending chronological ordering. It does not state that truncation is silent or that there is no pagination escape hatch.

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 action, then qualifies with entry types and ordering. Every clause carries information; nothing is redundant with the name or title.

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

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

For a parameterless, read-only list tool with no output schema, the description supplies exactly the information an agent needs to call and interpret it: scope (100 entries), ordering (newest first), and content (spends, purchases, referral rewards). 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?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to clarify about argument semantics.

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

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

States a clear verb and resource (list credit ledger entries) and enriches it with the entry types (spends, purchases, referral rewards), the 100-entry cap, and sort order. It implicitly differentiates from clipember_get_credit_balance by describing a history rather than a current balance, but it never names the sibling or explicitly contrasts the two.

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 fixed 'last 100, newest first' framing implies this is a recent-history browse, but the description gives no when-to-use guidance, no mention of when to prefer get_credit_balance, and no statement of what to do if more than 100 entries are needed. Usage is inferred 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, non-destructive, and closed-world behavior. The description adds the platform set and three connection states ('connected', 'need reconnecting', 'not connected'), which tells the agent what conditions it can detect; it does not add auth or rate-limit details, but those are not relevant for a read-only list.

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: the first defines the output and the second prevents misuse. No wasted words, and the core purpose 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?

For a simple read-only list tool whose annotations already cover safety, the description covers the platforms and statuses returned. With no output schema, it needn't explain the return structure, but it could have said more about the response shape (e.g., per-account status).

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

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

The tool takes zero parameters, and schema description coverage is 100%. Per the rubric, a zero-parameter tool has a baseline of 4, and the description adds no parameter semantics because none exist.

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 ('Show') and resource (platform connections), enumerates the platforms and the three connection states. An agent can distinguish it from clip/post/autopilot list tools without opening any schema.

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

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

Explicitly excludes connecting/disconnecting and points to the dashboard as the place for those actions. It implies the tool is for checking status but does not name a sibling alternative or prerequisites.

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

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

Annotations already declare the safe read-only, idempotent, non-destructive, closed-world profile, so the description need not repeat safety. It adds useful scope context ('not canceled', soonest-first ordering), but says nothing about result limits, pagination, or truncation behavior for a queue listing.

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 compact sentence that front-loads the action and includes the filter set, the exclusion, and the sort order with no wasted words.

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

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

For a simple filtered list whose annotations cover the safety profile and where no output schema exists, the description covers scope and ordering adequately. The only minor gap is that return shape and any pagination/limit behavior are 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?

The tool takes zero parameters, so the baseline is 4. The description adds no parameter detail because none exist, which is appropriate 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 names a specific verb (List) and resource (scheduled posts) and narrows scope to queued/posted/failed while excluding canceled. It distinguishes itself from write siblings like cancel/reschedule/retry, though it doesn't explicitly contrast with list siblings such as clipember_list_clips.

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: the tool is for inspecting the publishing queue, and the status filter and ordering tell the agent what it will see. However, there is no explicit when-to-use/when-not guidance or named alternative (e.g., versus get_clip or list_clips).

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the mutation/safety profile is covered. The description adds one genuinely useful non-obvious behavior — that an empty title resets the clip to the source video's title — but says nothing about permissions, failure modes, or side effects.

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

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

Two short sentences with the action front-loaded and the edge-case behavior immediately after; no filler. Slightly undermined by the imprecise 'project' wording, which costs a word of clarity rather than length.

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

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

For a two-parameter mutation with annotations covering the safety profile and no output schema, the description is close to sufficient, but the project/clip-request terminology mismatch and the unaddressed requestId leave gaps an agent must resolve on its own.

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

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

Schema description coverage is 0%, so the description must carry the burden. It explains the special semantics of 'title' (empty string resets to the source video title) but says nothing about 'requestId' beyond its UUID format, and omits the 200-character limit implied by the schema.

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

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

The verb is specific ('Rename') but the resource is stated as 'a project' while the tool name and title say 'clip request', leaving the agent to guess whether the two refer to the same entity. The empty-title reset clause is the only thing that makes this definition distinguishable from the other clip-request tools.

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

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

No statement of when to use this versus siblings such as clipember_get_clip_request or clipember_create_clip_request, and no prerequisites or exclusions. The empty-title reset is a usage hint for the parameter, not guidance for selecting the tool.

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

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

Annotations already cover readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds a meaningful state precondition and failure mode ('still-queued', 'fails if already posted or failed') beyond those annotations, though it does not describe permissions, return behavior, or what exactly is changed.

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

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

Two short sentences with no waste, and the core action and constraint are front-loaded. Every sentence earns its place.

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

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

For a simple two-parameter mutation with rich annotations and schema-provided formats, the description covers purpose, precondition, and failure mode. The missing parameter semantics are penalized separately, and no output schema means return values need not be described here.

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

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

Schema description coverage is 0% and the description only maps 'post' to postId and 'new time' to scheduledFor. It adds no format, timezone, or constraint detail beyond the property names, so it does not compensate for the 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?

The description states a specific verb ('Move') and resource ('a still-queued post') with a clear outcome ('to a new time'). The 'still-queued' qualifier distinguishes it from retry_failed_post and cancel_scheduled_post, so an agent can identify the correct operation without opening the schema.

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

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

It gives a clear use condition ('still-queued') and an explicit failure condition ('already posted or failed'), which effectively communicates when the tool applies and when it does not. It stops short of naming an alternative tool for failed posts, so it earns a 4 rather than 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 this is a non-read-only, idempotent, non-destructive, open-world operation, so the bar is lower. The description usefully adds that the publish happens 'right now' (immediate, not queued for a schedule), but it doesn't say what happens if the post isn't in a failed state or what errors surface.

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

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

A single short sentence with the action front-loaded and no filler. It is efficient, though its 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?

For a simple single-parameter mutation with annotations covering safety and idempotency, the description is minimally adequate. It omits prerequisites (post must be failed) and outcome/error behavior, with no output schema to fill that gap.

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

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

Schema description coverage is 0% and the description only implies postId refers to the failed post; it adds no format, source, or lookup guidance beyond that. With one undocumented parameter 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 ('Requeue ... to publish again') and a specific resource ('a failed post'), making the operation distinct from siblings like reschedule_post or cancel_scheduled_post. It stops short of explicitly naming those alternatives, 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?

No when-to-use or when-not-to-use guidance: it never says the post must currently be in a failed state, nor points to reschedule_post when the intent is to change timing rather than retry now. The agent must infer context from the tool name alone.

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 readOnlyHint=false, so the safety profile is covered. The description still adds real value beyond them: the blast radius ('anything using it stops working immediately') and explicit irreversibility, which tells the agent the impact extends to dependent clients, not just the key record.

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 verb and target, then the consequence and irreversibility. Every clause earns its place and nothing is padded.

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 destructive mutation with annotations covering safety and no output schema, the description supplies what an agent needs: the target, the id source, and the consequence. It omits only minor details such as the response shape or behavior when the key is already revoked (relevant despite the idempotent hint).

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

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

Only one parameter and schema description coverage is 100%, so the schema already documents keyId as a UUID sourced from clipember_list_api_keys. The description repeats that provenance but adds no format, validation, or edge-case detail beyond the schema — the correct baseline of 3 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 ('permanently revoke an API key') with the targeting key ('by id'), and names the sibling tool that produces that id. An agent can distinguish this from clipember_list_api_keys and the other clipember mutators without opening a schema.

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

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

Gives clear context: the id must come from clipember_list_api_keys, and the action is irreversible, which tells the agent this is a last-resort operation. It does not explicitly name an alternative or state when-not-to-use (e.g., rotation vs. revocation), 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?

Adds substantial context beyond the annotations: the 'WILL publish publicly later' side effect, strict sequential ordering ('a part never goes out before the previous one'), the on-screen/caption text injected ('PART n/N'), the TikTok Inbox limitation, and the concrete idempotency mechanism (skip already-queued parts). This goes well past idempotentHint/destructiveHint and tells the agent exactly what happens on a second call.

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

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

Front-loaded with the core action, then tightening constraints (ordering, idempotency, platform limit, publish warning) in descending priority. Four compact sentences, no filler or repetition of schema types.

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 timing, ordering, idempotency, side effects, and platform limits for a 4-param mutation with no output schema. The only minor gap is that it doesn't hint at the return value (e.g., which parts were queued vs skipped), though the skip behavior is described.

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

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

Schema coverage is already 75%, but the description reinforces semantics: gapMinutes governs the spacing between parts, startAt is when Part 1 goes out, and the series is defined via seriesId pointing at a series=true request. It clarifies how parameters interrelate (ordering + cadence) rather than just restating types.

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

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

Names a specific action (queue every part of a series) on a specific resource (a request created with series=true), in story order. It is clearly distinguishable from siblings like clipember_create_scheduled_post or clipember_reschedule_post because it explicitly scopes to multi-part series scheduling.

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

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

Gives clear triggering context (a request with series=true, chosen platforms) and an important constraint (TikTok unsupported; already-queued parts are skipped). It doesn't name a specific alternative tool for single-post scheduling, but the series-vs-single distinction is stated explicitly, which is the key routing decision.

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, openWorld), so the description's job is to add context. It does: results are limited to public videos and are not filtered to Creative Commons, which is a non-obvious licensing trait that affects whether a result is clip-eligible. It says nothing about result count or pagination, 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, front-loaded with the action, and the second sentence carries only decision-relevant routing and scope information. No filler.

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

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

For a one-parameter, annotated, read-only search tool with no output schema, the description covers purpose, routing, and licensing scope adequately. Only the result-shape behavior (how many videos, whether pagination applies) is left unstated, which is a minor 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?

Single parameter with 100% schema description coverage ('Search keywords'), so the schema already carries the meaning. The description's phrase 'keyword search' restates rather than extends the schema, so baseline 3 is appropriate.

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

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

Names a specific verb (search) and resource (public YouTube videos) plus the intent behind it (finding a source to clip). None of the siblings perform discovery, so an agent can trivially distinguish this tool from the clip-request and account-management tools.

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

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

Explicitly states when to reach for it: 'use this instead of asking the user for a URL when they only have a topic in mind.' It also adds a scope qualifier ('Not restricted to Creative Commons'), giving the agent a boundary condition rather than leaving usage 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=false, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds genuinely useful context beyond them: the link is 'public' and 'no-login' (an externally reachable, unauthenticated artifact) and that calling again reuses the active link rather than minting a new one.

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 with zero filler; the mutating/implicit-idempotency behavior is front-loaded. Every clause earns its place.

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

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

With one required parameter, no nested objects, and no output schema, the description covers the essentials plus the public/no-login and reuse semantics. Minor gaps remain: it does not say the response contains the URL, nor whether the link can later be revoked (no revoke-share sibling exists).

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

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

Schema description coverage is 0%, so the lone clipId parameter is documented only by its UUID format and pattern. The phrase 'for a rendered clip' adds a meaningful constraint (the clip must already be rendered), but the description omits what the ID refers to and where to obtain it.

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

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

States a specific verb ('Create (or reuse the active)') and a precise resource ('public, no-login share link for a rendered clip'). No sibling tool produces share links, so the agent can identify this action unambiguously from the name plus description.

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

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

Usage is only implied: an agent infers it should call this when it needs a shareable URL for a clip. There is no statement of when not to use it, no prerequisite (e.g. clip must already be rendered), and no alternative named, though the sibling list contains no real competitor for this action.

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

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

Annotations already declare this is a non-destructive, idempotent write (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description's 'clear (0)' is consistent with resubmission semantics. Beyond that the description adds little: it does not say whether ratings are per-user, whether prior feedback is overwritten, or what the call returns.

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

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

A single front-loaded sentence that enumerates the value domain with zero filler. Nothing could be removed without losing information.

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

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

For a two-parameter tool with full annotation coverage and no output schema, the description plus annotations give an agent enough to call it correctly. The only remaining gap is the absence of any statement about permission requirements or post-call effect.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning; it does so for the non-obvious parameter by naming what -1, 0, and 1 mean ('thumbs down', 'clear', 'thumbs up'), which the bare consts do not convey. clipId is left unexplained, but its name and uuid format make it self-evident.

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 (submit/rate) and resource (clip), and enumerates the meaning of each rating value. No sibling tool performs feedback submission, so the function is unambiguous, though it never explicitly positions itself against neighbors like clipember_get_clip or clipember_share_clip.

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

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

There is no guidance on when to use this versus alternatives, no prerequisites (e.g., must the clip belong to the caller?), and no statement about whether a rating can be changed or removed. Usage is only implied by the verb 'feedback'.

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 safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the bar is lower; the description adds genuine value by disclosing the negative scope (no email/password/delete) and the dashboard fallback. It still omits what happens to unmentioned fields and any auth/permission requirements.

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

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

Two tight sentences with zero filler; the capability is front-loaded and the boundary/redirect sentence follows immediately. Every clause earns its place.

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

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

For a two-parameter mutation with no output schema, the description covers what changes, what is off-limits, and where to go instead. It could add that omitted fields remain unchanged (implicit in the 'and/or' phrasing) and whether the updated settings are returned, but nothing critical is missing.

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

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

Schema description coverage is 100% — both parameters are documented, including null-clears-name and the partial emailPrefs patch semantics. The description only restates the two settings generically, adding no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb+resource ('Update the account's display name and/or email notification preferences') and bounds the scope by naming what cannot be changed. The read counterpart get_account_settings is an obvious sibling, but it is never named, so differentiation stays implicit.

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

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

Explicitly routes the agent away for the excluded operations: 'Cannot change email/password or delete the account — do that in the dashboard.' No exclusions are given for the covered operations or for when to read settings first, so it falls short of full when/when-not/alternatives coverage.

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