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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explicitly declares the tool is read-only, restricted to one's own handle, returns durable history in reverse chronological order, and includes delivery state. This is thorough transparency for a simple read-only audit tool.

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

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

The description is two short sentences that front-load the core purpose and then add essential constraints and output details. Every phrase earns its place with no redundancy or verbosity.

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

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

For a tool with one optional parameter and no output schema, the description covers the core behavior: what is shown, ordering, delivery state, read-only nature, and handle scope. It does not detail the exact output format or field list, which would make it fully complete, but nothing critical is missing for correct invocation.

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

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

The schema already documents the only parameter (limit) with a description and default, so the description need not repeat it. The description adds no additional parameter semantics, which is acceptable given 100% schema coverage.

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

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

The description uses a specific verb ('Show') and a concrete resource ('durable history of what capx has posted or attempted on your behalf'), and adds scope boundaries ('your own handle only'). This clearly distinguishes it from siblings like post_now or preview, making the tool's role unambiguous.

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

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

The description provides clear context for when to use the tool: it is a 'trust feature' for reviewing one's own posting/attempt history, and it is read-only. It does not explicitly name alternatives or state when not to use it, so it stops 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the two-phase choreography and the need for external browser authorization, which are essential behavioral traits. It does not discuss error handling or side effects, but the core interaction pattern is transparent.

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

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

The description is two sentences, front-loaded with the purpose and followed by the concrete usage pattern. Every word earns its place; there is no fluff or repetition.

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

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

The two-step flow is clearly explained, but with no output schema and no annotations, the description should also clarify the meaning of lane and clientId and the response shape beyond 'consent URL.' It is adequate for a high-level understanding but not fully complete for direct invocation.

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

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

Schema coverage is 0%, so the description must compensate by explaining the parameters. It only touches on confirm via the example { confirm: true }, while leaving lane and clientId completely unexplained. This is a significant gap for an agent trying to invoke the tool correctly.

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

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

The description clearly states the action: connect or confirm an X account via the capx chokepoint. It names the specific resource and mechanism, and it is easily distinguishable from sibling tools like post_now or upload_media, which target different resources and actions.

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

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

The description provides an explicit two-step usage protocol: call once for a consent URL, then call again with confirm:true after browser authorization. It does not explicitly mention alternatives or exclusions, but no sibling tool offers a competing connect flow, so the guidance is sufficient.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals non-obvious runtime traits: capx never generates content, firing only sends pre-written text, the loop pauses and asks for more when the queue empties, and an account-age prerequisite exists. This is exactly the kind of info an agent would otherwise discover only after invoking.

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

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

Three sentences, all substantive and non-redundant. The core purpose is front-loaded, and the behavioral caveats and requirement are delivered without fluff or repetition.

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

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

The definition plus schema gives the agent everything needed to invoke correctly: what the tool does, what content to supply, how the loop behaves, and a hard prerequisite. It is slightly short of complete because it doesn't indicate what the call returns or explicitly route to post_now for one-off posting, but neither blocks correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds genuine value beyond the schema for the `posts` parameter by making clear that the agent is solely responsible for authoring content and that capx will not fill in generated text. It doesn't add detail for time, timezone, or daysOfWeek, but those are already well documented in the schema.

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

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

The description opens with 'Schedule recurring posts,' a specific verb and resource that clearly states the tool's function. It also distinguishes this from siblings like post_now (one-off posting) and loop management tools (pause_loop, list_loops, delete_loop) by emphasizing recurrence and the loop lifecycle.

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

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

The description gives clear context: the agent must write the posts itself, capx never generates content, and a verified X account at least 30 days old is required. It doesn't explicitly name alternatives or say 'use this instead of post_now,' but the guidance is sufficient for correct use.

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

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

The word 'permanently' discloses the destructive, irreversible nature of the operation, which is valuable behavioral context in the absence of annotations. However, it does not mention other traits such as cascading effects, authentication requirements, or error behavior, leaving clear 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 front-loaded sentence with no redundant words. The qualifier 'permanently' adds meaningful behavioral information, and every word 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 one-parameter delete operation, the description is minimally adequate. However, without annotations or an output schema, the agent is left to infer side effects, error conditions, and return behavior, so completeness is only partial.

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

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

Schema description coverage is 0% for the single 'id' parameter, and the description does not explicitly explain what 'id' refers to. The tool name and resource mention imply it is the loop ID, but the description provides no direct parameter-level guidance to compensate for the schema's lack of 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?

The description uses a specific verb ('Delete') and resource ('loop') with the qualifier 'permanently', making the action unambiguous. It inherently distinguishes from sibling tools like pause_loop, which imply a non-destructive operation.

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 qualifier 'permanently' implies this tool is for irreversible deletion rather than temporary pauses, giving some implied usage context. However, it does not explicitly reference alternatives such as pause_loop or state when not to use this tool.

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

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

With no annotations to carry the safety profile, the description itself conveys that this is a read-only listing operation and clarifies the scope to the current user's loops. It adds useful detail about what is surfaced (next-post queue, paused state), though it does not mention authentication, ordering, or output limits.

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

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

One compact sentence that starts with the action and packs three useful facts about the result set. There is no filler and every phrase 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 zero-parameter read tool with no output schema, the description names the main return facets: scheduled loops, next-post queue, and paused status. It is nearly complete, though it could additionally specify the response format or any connection/auth requirement.

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

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

The tool has zero parameters, so there is no parameter meaning the description needs to add beyond the schema. The word 'your' adds useful scope context and is the only semantic clarification needed.

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

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

The description opens with a concrete verb, 'List', and identifies the exact resource: 'your scheduled loops'. It also names the distinctive content (next-post queue and paused status), which separates it cleanly from sibling tools like create_loop, pause_loop, and audit.

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

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

The description clearly implies that this is the tool to call when the user wants to see their scheduled loops. However, it does not explicitly state when to prefer it over alternatives such as audit or preview, nor does it provide any exclusions 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool pauses or resumes a loop, with no explanation of what pausing does to an active loop, whether the operation is idempotent, what side effects occur, or what happens on resume.

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

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

The description is a single, front-loaded sentence with no filler or repetition. It could be slightly more informative without losing conciseness, so it is strong but not perfect.

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 state toggle, the combination of the description and the schema is minimally viable: id is the required target and paused has an explicit schema description. However, it lacks behavioral context, return expectations, and any relationship to sibling loop tools, leaving the agent to infer too much.

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

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

Schema description coverage is only 50%, and the description names neither parameter. The agent must infer that id identifies the target loop and that paused controls the state; the description adds no parameter-level meaning beyond what the schema already provides.

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

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

The description uses a specific action—pause/resume—and identifies the resource as a loop, which clearly distinguishes it from siblings like create_loop, list_loops, and delete_loop. Even without naming alternatives, the operation is unambiguous for an agent choosing among the provided sibling tools.

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

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

There is no explicit guidance about when to use this tool versus alternatives, no conditions, and no mention of related tools such as create_loop, top_up_loop, or delete_loop. The only usage signal is the action phrase itself, which is implied rather than explicitly scoped.

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

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

With no annotations, the description carries full disclosure burden; it goes beyond the obvious by revealing a guardrail/chokepoint, that blocked/held posts are never sent, and that the token never touches this machine. It also discloses default-off AI labeling and reply chaining. It falls short only on idempotency and exact failure/return 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?

The description is compact and front-loaded with its core purpose before behavioral and parameter details. It is slightly dense with jargon ('casserole guardrail at the chokepoint'), but every sentence contributes substantive guidance.

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?

Core invocation is covered, but with no output schema the description should state what the tool returns (e.g., platformPostId for chaining replies), and it leaves idempotencyKey semantics unaddressed. It is adequate for a simple text post but not complete for advanced thread/retry usage.

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

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

Schema coverage is 60%, so the description must compensate for text and idempotencyKey, which lack schema descriptions. It adds clarity to aiGenerated (user choice, default off) and inReplyToId (platformPostId chaining), but leaves idempotencyKey completely unexplained and does not mention mediaIds.

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

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

The opening sentence names a specific action ('Post text to X now') with a concrete resource and immediacy, which distinguishes it from scheduling/preview siblings. The rest of the description reinforces it as a direct posting action, not a management or upload tool.

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

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

The description gives parameter-level conditions ('Set aiGenerated only if...', 'Pass inReplyToId...') but never states when to choose post_now over siblings like preview or create_loop, or when not to use it. No exclusions or alternatives are named.

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

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

With no annotations, the description fully carries the behavioral disclosure burden. It clearly communicates the non-destructive nature ('WITHOUT posting', 'linter'), what it returns (pass/held/blocked and why), and the guardrail caveat. It omits authentication or rate-limit details, but for a dry-run linter this is strong transparency.

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

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

Two sentences, front-loaded with the core action and constraints. Every clause earns its place: the dry-run behavior, return value, intended use case, and the warning that it is not a bypass. No fluff.

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

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

Given the simple 2-parameter schema, no annotations, and no output schema, the description covers the essential context: purpose, when to use, return value, and safety. The only notable gap is the undocumented aiGenerated parameter, preventing a perfect score.

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

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

Schema description coverage is 0%, so the description must compensate. It relates the required 'text' to 'a draft', but the optional 'aiGenerated' boolean is never mentioned. The agent gets no guidance on when or how to set that parameter, leaving a meaningful gap.

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

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

The description states a specific verb ('Dry-run'), the resource ('a draft through the casserole guardrail'), and the exact outcome ('returns whether it would pass, be held, or be blocked, and why'). 'WITHOUT posting' and the linter framing clearly distinguish it from siblings like post_now.

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

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

The description gives explicit timing ('before posting or scheduling') and a clear when-not ('never a way to bypass the guard'). It does not name alternative sibling tools explicitly, but the context makes it obvious that actual posting requires a different 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?

With no annotations, the description carries the behavioral burden. It discloses that the tool adds posts and resumes a paused loop, and it implies an ownership constraint with 'YOU wrote.' However, it does not clarify whether posts are appended or replace the queue, whether active loops can also be topped up, or what happens when validation fails.

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

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

The description is two short sentences with no filler. The first sentence states the core action and scope; the second adds the key resumption behavior. Every word 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?

The tool is simple, but the description omits important operational details: the meaning of 'id', the expected format of 'posts', and any side effects beyond resuming a paused loop. It is sufficient for a rough understanding but not fully self-contained given the absent annotations and minimal schema.

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

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

Schema description coverage is 0%, so the description must compensate. It gives partial meaning to 'posts' by saying they are posts YOU wrote and belong in a loop's queue, but it never explains what the strings should contain (IDs, text, media URLs?). The 'id' parameter is not described at all, leaving it ambiguous whether it is the loop ID or something else.

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

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

The description uses a specific verb ('Add'), names the resource ('a loop's queue'), and adds a clear scope ('posts YOU wrote'). It also distinguishes the tool from siblings like create_loop and post_now by stating it operates on an existing loop queue and can resume a paused loop.

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

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

The description gives a clear when-to-use condition: add posts when a loop paused because it ran out of content. It does not explicitly list alternatives or when not to use the tool, so it stops short of full routing guidance.

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

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

With no annotations, the description carries the burden and does well: it discloses the read-and-stream behavior, the returned media id, and the notable non-moderation/labeling policy. It doesn't cover permissions, failure modes, or side effects, but it is far beyond a bare mutation statement.

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 purpose-built sentences: one for what/why, one for mechanism and result, one for moderation policy. It is front-loaded with the key action and no sentence is wasted.

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

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

For a one-parameter tool with no output schema, the description covers the necessary call flow, return value, and important policy context. It omits format/size limits and error behavior, but these are minor for basic invocation.

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

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

Schema coverage is 100% and includes an example, so baseline is 3. The description adds meaningful constraint: path must be a local media file 'produced by your own media tool' and the bytes are streamed, which clarifies what the parameter should hold beyond the schema's generic wording.

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

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

The description uses a specific verb and resource: 'Upload a local image or video... so it can be attached to a post.' It also names the downstream consumer (post_now) and the returned media id, making the tool's role distinct among siblings.

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

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

It clearly connects upload_media to the post-creation workflow ('returns a media id to pass to post_now'), indicating when to use it. It doesn't explicitly state when not to use it or compare with alternatives, but the context is clear enough for an 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?

With no annotations provided, the description carries the behavioral disclosure burden. It states that the tool returns the connected account and its status, and adds the specific mechanism 'via the chokepoint'. While it does not describe error cases or output formatting, it clearly conveys a read-only status operation.

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

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

The description is a single sentence with no filler. It front-loads the main action and object, and every word adds meaning.

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 zero-parameter identity lookup, the description is largely sufficient: it names both the returned information and the source. It could be slightly stronger with an explicit statement about expected use after connect_x, but nothing essential is missing for invocation.

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

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

The input schema has zero parameters, so parameter semantics are not a concern. Schema description coverage is 100%, and the description does not need to document parameter behavior that does not 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?

The description uses a specific verb, 'Show', and a clear resource, 'the connected X account and its status'. It is immediately distinguishable from sibling tools like connect_x, post_now, and preview, which all perform different actions.

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

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

The description clearly implies the tool is for checking which X account is currently connected and its status, which is a distinct context among the sibling tools. It does not explicitly state exclusions or compare against alternatives, but the usage context is clear for a zero-parameter identity/status tool.

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