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

Annotations only say the tool is not read-only and has no open-world hint; the description adds the important guard that live agents require confirm=true and that digest agents never transmit replies/DMs. This goes beyond the structured data and materially affects how the tool should be invoked.

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 pack the core action, the configuration parameter, the confirmation guard, and an agent-behavior caveat with no filler. The most important operational information 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 moderate 4-parameter mutation tool with no output schema, the description covers what the tool does, the confirm guard, and the digest behavior exceptions. It is missing a little context around how an agent determines whether an agent is 'live' and what the returned result looks like, but these are minor given the schema and sibling list.

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

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

With 0% schema description coverage, the description compensates by mapping enabled to on/off, every_ms to the interval to set, and confirm to a live-agent confirmation flag. Some agent_id values (publish_queue, health) are left to the schema enum, but the most decision-relevant parameter semantics are present.

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 the action directly ('Turn an agent on/off and set every_ms'), giving a clear verb and resource. It does not explicitly distinguish itself from sibling tools, but the behavior is specific enough to separate it from listing and scheduling tools.

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

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

The description signals a key precondition ('Live agents (if any) need confirm=true') and a meaningful exclusion ('mention_digest / inbox_digest never send replies or DMs'), which helps an agent decide when not to use those agent IDs. It does not explicitly point to alternatives, 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?

Annotations provide readOnlyHint=true, and the description adds specific behavioral context: digests never auto-reply, they snapshot, and optionally POST webhook_url for Claude/ChatGPT/AdvisorPPC. This goes beyond the annotation by explaining the nature of the agents being listed, which helps the agent anticipate what these agents do. No contradiction with readOnlyHint.

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 filler. The agent names are front-loaded, and the digest behavior clarifies important non-obvious characteristics. It's concise and relevant, though the first sentence is a fragment rather than a complete sentence.

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?

This is a simple zero-parameter, read-only list tool with annotations covering safety. The description provides the list of agents and additional behavior notes for digests, which is sufficient for an agent to understand the tool's purpose and output. It could explicitly state the return format, but this 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 has zero parameters and the input schema is empty, so schema coverage is trivially complete. The description is not required to elaborate on parameters, and with 0 params the baseline is 4.

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 title clearly says 'List scheduler agents' and the description enumerates the exact built-in agent names (publish_queue, mention_digest, inbox_digest, health), making the resource unambiguous. However, the description is a fragment rather than an explicit sentence like 'Lists all built-in scheduler agents,' so it's clear but slightly 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?

No explicit guidance on when to use this tool versus siblings such as x_organic_agent_set or x_organic_scheduler_status. It does not say 'use this to see available agents before configuring' or mention alternatives, leaving the agent to infer the use case from the title and list.

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

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

Annotations already indicate readOnlyHint=false and openWorldHint=true, so the mutation/side-effect nature is covered. The description adds the HTTP method and required OAuth scope 'bookmark.write', which is useful, but it does not explain duplicate bookmark behavior, idempotency, or what changes occur beyond the obvious bookmarking action.

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 concise sentence with no filler, and the endpoint is front-loaded. It is appropriately short for a one-parameter tool, though it sacrifices useful context.

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 tool with one parameter and no output schema, the description is too thin: it omits post_id semantics, mentions an endpoint path parameter ':id' that is not in the input schema, and gives no sense of result or failure behavior. An agent could likely invoke it, but only by relying heavily on the tool name and common sense.

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 for the undocumented parameter, but it does not explain how to obtain or format post_id. The parameter name is self-explanatory at a high level, but the tool still lacks explicit semantic guidance.

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

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

The title 'Bookmark a post' plus the POST endpoint make the operation clear: this saves a post to the user's bookmarks. It is distinguishable from siblings like x_organic_unbookmark and x_organic_list_bookmarks, though it does not explicitly compare itself to them.

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 no guidance about when to use this tool versus alternatives such as x_organic_unbookmark or x_organic_list_bookmarks. The scope line implies an auth requirement, but there is no stated context, prerequisite, or exclusion.

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 convey that the tool writes to the open world. The description adds significant behavioral detail: never invent content, require explicit confirmation, pay-per-use costs, link-warning obligation, absence of native scheduling, and media type limits. No contradiction with annotations is present.

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

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

Every sentence adds operative guidance, and high-priority constraints are front-loaded: content provenance, confirmation requirement, and costs. The description is dense but not bloated, and it avoids repeating schema fields unnecessarily.

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

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

For a high-complexity write tool with no output schema, the description covers confirmation, media sourcing, cost, link warnings, and scheduling boundaries very well. The main gaps are the absence of guidance on reply_settings and what the tool returns on success, though the enum covers the former partially.

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 25%, so the description carries much of the burden. It adds real meaning for confirm (must follow explicit named ask) and media_ids (must come from x_organic_upload_media, max 4 photos/1 GIF/1 video). However, text and reply_settings receive no description-level guidance beyond their schema types/enum.

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 identifies the action as creating a tweet via 'POST /2/tweets' and adds important scope constraints ('Use only the copy/media the user supplied'). It is distinct from scheduling tools, but it does not explicitly distinguish itself from sibling post-creation tools like x_organic_create_thread, x_organic_reply, or x_organic_quote.

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 conditions: confirm=true is required after an explicit named ask, links require a warning, and scheduling must be delegated to x_organic_schedule_* tools rather than inventing a publish time. It also points to x_organic_upload_media for media_ids. However, it does not directly state when to choose this tool over reply/thread/quote siblings.

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 only readOnlyHint=false and openWorldHint=true, the description carries the behavioral burden and does so thoroughly: it discloses the composite publishing sequence, failure semantics (STOP and return), cost per post, link warning requirement, and lack of native scheduling. No contradiction with 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?

Dense and front-loaded: the composite definition comes first, followed by operationally critical rules. Every sentence contributes unique guidance (confirmation, failure, cost, scheduling) 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?

Given the complexity, the description covers invocation, confirmation, failure, cost, and scheduling, and even indicates what to return on partial failure. It would be complete if it also addressed reply_settings and media handling, but those are partially inferable from the schema.

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

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

Schema coverage is only 33%, but the description adds substantive semantics for posts (the array represents thread copy, first post then replies, never invent content) and confirm (once per whole thread). Reply_settings is not addressed in the description, leaving one parameter 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 first sentence defines the operation as a composite: publish the first post and chain the remainder as replies, which is specific and distinct from x_organic_create_post or x_organic_reply. It names the resource (thread) and the exact behavior.

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

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

The description gives explicit usage constraints: use only user-supplied copy, never invent posts, require confirm=true once, and stop on failure. It also routes scheduling to AdvisorPPC x_organic_schedule_* tools, making the alternative explicit.

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

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

Annotations already mark the tool as destructive and non-read-only; the description adds meaningful behavioral context by stating the operation is irreversible, restricted to authored posts, and only allowed after explicit user confirmation. This goes beyond the structured hints.

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, each carrying distinct information: endpoint, ownership restriction, confirmation requirement, and destructiveness. 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 destructive action with two parameters and no output schema, the description covers what is needed to invoke it safely: what it deletes, who may delete, what must be confirmed, and that it is irreversible. The destructive annotation is reinforced rather than contradicted.

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 description clarifies post_id as the ID of a post the user authored via the endpoint and ownership note, and it reinforces the confirm parameter's purpose by tying it to the user naming the exact post. Schema already documents confirm well, but post_id benefits from the description.

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

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

Description states a specific verb ('delete'), a resource ('posts'), and a scope restriction ('only delete posts you authored'), and identifies the endpoint. This distinguishes it clearly from sibling tools that create, reply, quote, or repost rather than delete.

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 condition for use: deleting a post authored by the user, with explicit confirmation required after the user names the exact post. However, it does not explicitly mention alternatives or when not to use this tool beyond the ownership restriction, leaving some inference to 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 supply readOnlyHint=true, so the safety profile is known. The description adds the crucial OAuth2 token context and implies that the result is tied to the authenticated session, which is behaviorally useful. It does not contradict the annotations and adds value beyond them by clarifying the identity source.

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 plus a direct warning. It front-loads the HTTP endpoint and purpose first, then gives usage context, and ends with an actionable caution. No redundant words or 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 zero-parameter, read-only tool with no output schema, the description provides all necessary operational context: what it returns (the current user), when to invoke it, and a critical anti-pattern (don't invent a handle). Nothing an agent needs to call it correctly is missing.

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

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

With zero parameters, the schema is fully covered (100%) and there is nothing for the description to add. The baseline for 0-parameter tools is 4, and the description appropriately avoids inventing parameter details.

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 resource ('the user on this OAuth2 token') and the HTTP verb ('GET'), making it unambiguous. It also distinguishes itself from sibling lookup tools by noting it is the authenticated user, not an arbitrary one, and names the downstream use cases (timeline, likes, bookmarks, mentions).

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

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

It explicitly tells the agent when to use this tool ('Call first when you need user id for timeline, likes, bookmarks, or mentions') and warns against fabricating handles ('Never invent a handle'). This effectively routes the agent away from alternative lookup tools without cluttering the description.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description does not need to restate safety. It adds value by disclosing that the response expands to include public metrics, author, media, and referenced posts, which sets caller expectations. No contradiction with annotations.

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

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

The description is a single concise sentence with the core operation front-loaded. It contains no filler, and every element—endpoint, parameter, and returned data—contributes to understanding.

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 GET with read-only annotations, the description covers the operation, parameter, and key response components. It does not detail the exact output schema or error behavior, but that level of detail is not essential for selecting and invoking this 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?

Schema coverage is 0%, so the description carries the burden of clarifying the parameter. The route '/2/tweets/:id' identifies post_id as the tweet ID, and the title reinforces this, but no additional format details, examples, or edge-case constraints are provided beyond the schema's minLength.

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?

Description states a specific operation ('GET /2/tweets/:id') and its resource, making it clear the tool fetches a single post by ID. It also lists returned components (public metrics, author, media, referenced posts), which differentiates it from plural lookup tools like lookup_posts.

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

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

The name 'Get one post' and the endpoint imply it is for retrieving a single tweet by ID, but no explicit guidance is given about when to choose this over sibling tools. Alternatives and exclusions are not mentioned, so usage context is only inferred.

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

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

Annotations already declare readOnlyHint=true, covering the read-only nature. The description adds a valuable caveat: quote creation is Enterprise-only but reading is not, which clarifies availability for self-serve users. However, it does not mention pagination behavior or return format, and given the openWorldHint, some uncertainty remains. The description adds some context beyond annotations but not rich behavioral detail.

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

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

The description is very short (two sentences) and front-loaded with the endpoint. It is efficient with no fluff, though it omits critical details. The conciseness is good, but the sparsity borders on under-specification.

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 3 parameters, no output schema, and limited schema descriptions, the description is inadequate. It fails to explain what post_id refers to, how max_results and pagination_token work, or what the response looks like. An agent would need external knowledge to call this correctly. The annotations cover read-only safety but not operational details.

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

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

Schema coverage is only 33% (only pagination_token has a description). The description does not explain post_id, max_results, or pagination_token usage at all. With low schema coverage, the description should compensate, but it provides zero parameter information, leaving the agent to guess the meaning and constraints of the 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 clearly states the endpoint and the resource: it retrieves quote tweets of a post (GET /2/tweets/:id/quote_tweets). It also clarifies that this is a read operation, distinguishing it from quote creation. However, it does not explicitly differentiate from sibling retrieval tools like x_organic_get_post, though the title is specific enough.

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 does not provide explicit guidance on when to use this tool versus alternatives. It only notes the Enterprise restriction on creation, which is tangential to usage selection. No when-to-use or when-not-to-use scenarios are given, leaving the agent to infer from the title and sibling names.

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

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

Beyond the readOnlyHint=false and openWorldHint=true annotations, the description adds the HTTP endpoint, the ownership restriction, the required confirm flag, and the OAuth scope. This gives an agent the necessary behavioral context without contradicting 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?

Four short, dense clauses deliver the HTTP method, path, ownership constraint, confirm requirement, scope, and parameter semantics with zero filler. The most important usage restriction 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 mutating tool with no output schema, the description is nearly complete: it covers the endpoint, prerequisites, ownership, scope, and parameter behavior. The only gap is that it does not describe the expected response or common error conditions, but these are not essential for invoking the tool.

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

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

Schema coverage is 100%, so baseline is 3üssig. The description adds value by framing reply_id as the :id in the path and tying it to the 'reply on a conversation you own' rule. It also reinforces the hidden boolean semantics, complementing rather than merely repeating 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?

Title and description both clearly state the action: hide or unhide a reply. The description explicitly maps hidden=true to hide and false to unhide, and the verb-resource pair is unambiguous. None of the siblings overlap with this hide/unhide semantics, so it stands apart.

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 states clear usage context: it only works for replies on a conversation you own, and it requires confirm=true and scope tweet.moderate.write. It does not explicitly name alternatives or say when not to use it, but the ownership limitation effectively scopes it.

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

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

With readOnlyHint=true and openWorldHint=true already in annotations, the description adds useful behavioral context: the tool is composite, surfaces only the last message per conversation, and must not auto-reply. No annotation contradiction is present.

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

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

Two short sentences front-load the behavior, then the workflow, then the guardrail. Every clause earns its place; there is no redundant phrasing or 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 composite fetch/group tool with no output schema, the description explains what is delivered, when to use it, and the safe following actions. The only real gap is the complete absence of parameter guidance.

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

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

Input schema coverage is 0%, and the description does not explain max_results or max_conversations. The parameter names and numeric bounds in the schema are self-explanatory, but the description adds no meaning about what each parameter controls or how they interact.

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 composite operation: 'fetch recent DM events and group by conversation with the last message.' This clearly identifies the tool as an inbox summary and distinguishes it from raw DM-event listing or sending tools.

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

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

The description explicitly routes the agent: 'Use this to triage inbox, then x_organic_list_dm_conversation + x_organic_send_dm (confirm) to answer. Do not auto-reply.' It provides a concrete workflow and a hard constraint, making the tool's role clear relative to siblings.

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 indicate a write operation (readOnlyHint=false); the description adds that the like is reversible, requires like.write scope, and should not be performed in bulk. This provides useful behavioral context beyond the structured annotations.

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

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

The description is exceptionally concise, with four short fragments and no filler. Every fragment conveys a distinct piece of information, and the endpoint 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 one-parameter mutation tool, the description covers the key operational aspects: endpoint, auth scope, reversibility, and the anti-bulk constraint. It does not describe the response format, but the lack of an output schema and the tool's simplicity make this acceptable.

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 does not explain the post_id parameter at all. The endpoint and title imply that a post is targeted, but no additional semantic value is provided beyond the parameter name and type.

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

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

The description states a specific verb ('Like') and resource ('a post'), reinforced by the exact endpoint 'POST /2/users/:id/likes'. This clearly distinguishes it from sibling tools such as x_organic_unlike and x_organic_bookmark.

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 usage context by noting the action is reversible, requires scope like.write, and explicitly warns 'Do not mass-like.' It does not name an alternative for undoing a like, but the constraints it provides are sufficient for most decisions.

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, so the safety profile is covered. The description adds one meaningful behavioral detail—defaulting to the authenticated user—but does not mention pagination behavior, response shape, or any rate-limit/auth nuances. It adds some context beyond the annotations but not much.

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 two-sentence definition with no filler, and the endpoint is front-loaded. It is appropriately short for a simple read-only list tool, though one additional sentence about pagination or return contents would not have hurt.

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 optional-parameter GET endpoint, the description plus schema covers the basics: what resource is accessed, optional user_id, max_results bounds, and pagination token source. However, without an output schema, the absence of any information about the shape or contents of the response leaves an agent to infer those details from endpoint semantics alone.

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

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

Schema description coverage is only 33%, so the description must compensate, but it only clarifies user_id implicitly via 'Defaults to the authenticated user.' max_results is left entirely to its name and min/max bounds, and pagination_token only repeats the schema's brief 'from a previous meta.next_token' hint. The tool description does not meaningfully enrich the 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?

The description identifies a specific endpoint (GET /2/users/:id/liked_tweets) and a clear resource: a user's liked posts. The title and endpoint make it distinguishable from sibling tools like x_organic_user_posts and x_organic_list_bookmarks, though it relies on endpoint naming rather than a plain-language statement of behavior.

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

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

There is no guidance on when to select this tool over related alternatives such as list_bookmarks, user_posts, or my_timeline. The phrase 'Defaults to the authenticated user' gives some context about the user_id parameter, but no scenario, exclusions, or sibling comparisons are provided.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds the authentication requirement and the required OAuth scope (bookmark.read), which is useful. However, it does not disclose pagination behavior, default max_results, or response format—gaps that are not filled by annotations.

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

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

The description is extremely terse—just one line—with no wasted words. It front-loads the HTTP method and path. However, it is so brief that it borders on under-specification rather than efficient conciseness, but it still earns a 4 for lack of 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?

For a simple read-only list tool with two optional parameters and no output schema, the description is mostly adequate: it states the purpose and auth requirement. However, it lacks details on pagination usage, default max_results behavior, and potential error cases, leaving an agent to guess on some operational aspects.

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

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

Schema coverage is only 50%: pagination_token has a description, but max_results does not. The description adds no parameter information whatsoever, so it fails to compensate for the missing schema documentation. An agent gets no help understanding max_results or how to use pagination_token beyond the schema's single description.

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

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

The description clearly states the verb (GET), resource (bookmarks), and scope (for the authenticated user), which precisely distinguishes it from sibling tools like x_organic_bookmark and x_organic_unbookmark that perform actions on bookmarks. It is unambiguous and specific.

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 no guidance on when to use this tool versus alternatives, nor any conditions or exclusions. It is implied that one would use it to list bookmarks, but no context about when not to use it or how it relates to other list tools is given.

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

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

Annotations already cover readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds the HTTP method GET, the specific OAuth scope dm.read, and the source for the conversation id—contextful details beyond the annotations. It does not describe pagination or response format, but those are less critical given the read-only annotation.

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 extremely concise—two sentences that front-load the endpoint and the key prerequisite. Every word earns its place with no redundancy.

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

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

For a simple read-only tool with only 3 parameters, no output schema, and read-only annotations, the description plus schema are nearly sufficient. It covers purpose, id source, and scope; pagination behavior is inferable from parameter names but not explicitly stated, 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?

Schema description coverage is 0%, and the description only indirectly references the dm_conversation_id parameter. It does not explain max_results or pagination_token, so the description fails to compensate for the complete absence of parameter documentation 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 clearly states the tool reads DM events via the GET /2/dm_conversations/:id/dm_events endpoint and requires a conversation id. It identifies the resource and gives a source for the id, but it does not explicitly distinguish this tool from the sibling x_organic_list_dm_events, which may have overlapping functionality.

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 usage context: you need a conversation id from inbox_summary or list_dm_events, and it specifies the required scope dm.read. It does not name alternatives to avoid, but the prerequisite and scope give enough guidance for correct selection.

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

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

Annotations already provide readOnlyHint and openWorldHint, but the description adds valuable context: the required OAuth scope (dm.read), the event type (MessageCreate), and a content-safety rule ('Do not dump DMs into public posts'). This goes beyond the structured annotations without contradicting them.

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 extremely concise and well-structured, leading with the HTTP verb and resource, then scope, then a behavioral warning. Every sentence adds useful information with no filler.

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

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

With three undocumented optional parameters and no output schema, the description leaves critical details unresolved—what dm_event_fields accepts, how pagination_token is used, and what a response looks like. The tool is simple, but the lack of parameter semantics makes it incomplete for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate, but it does not explain max_results, dm_event_fields, or pagination_token at all. The only weak hint is 'One page' suggesting pagination, but that is insufficient given zero parameter documentation.

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 operation ('GET /2/dm_events', 'List DM events') and specifies the resource and scope: 'One page of inbox events with sender expansion.' It differentiates from sibling tools like list_dm_conversation and inbox_summary by focusing on event-level listing with a specific event type (MessageCreate).

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

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

No explicit guidance on when to use this tool over list_dm_conversation or inbox_summary is provided. The phrase 'One page of inbox events' implies pagination but does not explain when an agent should choose this tool or when to use a sibling instead.

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

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

Even with readOnlyHint=true and openWorldHint=true already present in annotations, the description adds meaningful behavioral context: it is a 'recent-search composite' (indicating the search-based nature and open-world sourcing), and 'Billed per matching post' discloses the cost model. It also adds a social/interaction rule ('confirm required; self-serve only if they summoned you'). No contradiction with annotations.

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

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

Three sentences, each earning its place: the composite query, the intended use, and the follow-up/billing/policy caveats. The most identifying information (purpose and mechanism) is front-loaded, and there is no redundant restatement of the title or schema.

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

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

For a list tool with three parameters and no output schema, the description covers the essential operational context: what it lists, how the query works, the billing implication, and the required follow-up action. The main gap is that the return shape is not described, but the purpose 'list replies' and the 'recent-search composite' hint make the output reasonably inferable. This is a strong but not exhaustive definition.

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

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

Schema coverage is only 33%, so the description carries more responsibility for parameters. It clarifies post_id's role via the query fragment 'conversation_id:{post_id}', which adds meaning beyond the bare schema. However, max_results is not explained in the description (though its bounds and self-explanatory name help), and pagination_token is already described in the schema. This partial compensation justifies a middle score.

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

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

The description states a specific verb and resource ('List replies to a post') and gives the underlying mechanism ('Recent-search composite: conversation_id:{post_id} is:reply'), making the tool's purpose unambiguous. It also names x_organic_reply as the follow-up step, which indirectly distinguishes it from the many mutation tools in the sibling list, though it doesn't explicitly contrast with other list/search 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?

It gives clear when-to-use context ('Use this to triage comments') and practical constraints ('Billed per matching post'). It also routes the agent to the next tool ('Then reply with x_organic_reply') and states the self-serve policy ('only if they summoned you'), which is actionable guidance. It doesn't explicitly say when NOT to use it or name alternative listing tools, but the guidance provided is concrete.

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 communicate that this is read-only and open-world, and the description adds a useful constraint: it supports up to 100 IDs via GET /2/tweets. However, it does not disclose what the response contains or how missing or invalid IDs are handled.

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

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

The description is one short sentence with the endpoint front-loaded and no filler. The trailing phrase 'the user named' is somewhat unclear and prevents a perfect score.

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

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

For a simple one-parameter read-only tool, the description is minimally adequate, especially with annotations covering safety and scope. But with no output schema, it does not tell the agent what response shape to expect or how partial results are returned.

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 needed to clarify parameter semantics, but it only restates the 100-ID cap already present in maxItems. It does not explain what valid post IDs look like, whether IDs need prefixes, or how the IDs map to the endpoint.

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

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

The description names the exact endpoint (GET /2/tweets) and the ?ids= parameter, making clear that this tool looks up posts by a list of IDs. It is specific enough to be understood, but it does not explicitly differentiate itself from siblings like x_organic_get_post or x_organic_user_posts.

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

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

No guidance is given about when to choose this tool over alternatives. An agent is not told to use this when it has a list of post IDs, nor told to prefer x_organic_get_post for a single post or x_organic_user_posts for a user's timeline.

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 and openWorldHint. The description adds value by naming the concrete GET endpoints and clarifying the lookup is by username or numeric ID, without contradicting 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 short sentences with no filler; the action and lookup keys are front-loaded, and the endpoint detail forms a useful second sentence without unnecessary explanation.

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 lookup with no output schema, the description adequately identifies the two input choices and the endpoint behavior. It leaves the exactly-one-parameter constraint implicit, but the schema descriptions and readOnlyHint cover most of what an agent needs.

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

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

Schema coverage is 100% and both parameter descriptions already document numeric user_id and @-less username. The description restates these and adds the endpoint mapping, but provides little semantic value 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?

Opens with 'Look up a user by username... or by numeric id', naming the exact resource, action, and lookup keys. The title 'Lookup one user' plus the singular wording clearly distinguishes it from sibling x_organic_lookup_users.

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

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

The description implies this is for exact user lookup and warns not to invent @handles, but it does not explicitly contrast with x_organic_lookup_users, x_organic_search_users, or state when to choose this tool over those alternatives.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds the XOR input constraint and the 'never invent handles' caution, but it does not disclose output shape, missing-identifier behavior, or any API-level quirks beyond 'comma-separated v2.'

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

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

Three short sentences with the primary action front-loaded and no filler. The constraints are dense but each 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 read-only lookup with two parameters, the description covers the crucial input rule and guardrail. However, with no output schema and no mention of return values or errors, an agent still has to infer what the batch lookup returns and how failures are surfaced.

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 does clarify the key relationship between user_ids and usernames (XOR) and the batch style, but it leaves format details (e.g., exact identifier forms and what 'comma-separated v2' means against the array schema) implicit.

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 'Batch lookup,' naming a specific verb and indicating the plural resource, which distinguishes it from the singular x_organic_lookup_user sibling. The XOR input instruction reinforces that this is a bulk identifier-based user lookup.

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 indicates how to invoke the tool ('Pass usernames XOR ids') and gives a guardrail ('Never invent handles'), but it does not explicitly say when to prefer this over x_organic_lookup_user or x_organic_search_users. The usage context is implied by 'Batch lookup' rather than stated as a decision rule.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and external data changes. The description adds the user-scope detail but does not disclose pagination behavior, response shape, or rate limits. It is consistent with annotations, so the bar is lower, but additional context beyond the safety profile is minimal.

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, direct sentence that front-loads the endpoint and key scope. There is no wasted language, and the structure efficiently conveys the core function.

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 listing tool with three optional parameters and no output schema, the description is adequate but incomplete. It does not describe the return format or pagination behavior beyond the token parameter, which an agent would need to correctly interpret results. Given the lack of an output schema, more detail on response contents would be expected.

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 33% (only pagination_token has a description). The description clarifies user_id by indicating it can be the authenticated user or a managed user, which adds value. However, max_results is left unexplained in both schema and description, so the description only partially compensates 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?

The description clearly identifies the tool as retrieving mentions for a user via a specific GET endpoint, and specifies the user scope (authenticated or managed). It names the resource 'mentions' distinctly from siblings like posts or timeline, but does not explicitly contrast with similar list tools such as x_organic_user_posts or x_organic_my_timeline.

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 no guidance on when to use this tool versus alternative listing tools. It implies it is for viewing mentions but does not state conditions, exclusions, or reasons to choose it over siblings, leaving the agent to infer usage.

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 provide readOnlyHint and openWorldHint, covering the safety profile. The description goes beyond this by adding 'Billed per read,' which discloses a cost implication, and by explicitly noting that the resource belongs to the authenticated user, adding useful auth context not present in the annotations.

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

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

The description is a single sentence with no filler. It front-loads the endpoint, immediately states the user scope, and adds the billing note—every word carries meaning. This is exemplary conciseness.

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 straightforward read-only list endpoint, the combination of endpoint path, 'home feed,' and billing note provides enough context to call the tool correctly. There is no output schema, so a more detailed description of the return shape could be helpful, but the 'timeline' semantic and the parameter schema cover the essentials. Minor gaps around response contents prevent a 5.

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

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

Schema description coverage is 50%: pagination_token has a description in the schema, but max_results has none. The tool description adds no parameter information at all, failing to compensate for the missing max_results semantics. It does not explain that max_results controls the number of returned items or that pagination_token continues a previous response.

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

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

The description names the exact endpoint (GET /2/users/:id/timelines/reverse_chronological) and clarifies it serves the authenticated user's home feed. This is a specific verb+resource with clear scope, and it is distinct from sibling tools like user_posts or search_recent, which operate on other data views.

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

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

The phrase 'for the authenticated user (home feed)' implies when the tool should be used, but it does not explicitly mention alternatives or provide exclusion criteria. There is no explicit routing to a sibling tool for other timeline needs, so the guidance remains implicit rather than direct.

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 are minimal (readOnlyHint=false, openWorldHint=true), so the description carries the full burden. It discloses that this is a mutation (POST), requires user confirmation, has plan-specific restrictions, includes pricing details, and enforces content integrity rules. This goes well beyond annotations and provides crucial operational context.

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

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

The description is three sentences, each dense with actionable information. It front-loads the endpoint and confirmation requirement, then covers restrictions, pricing, and content policy. No wasted words; 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 mutation tool with no output schema, the description covers the essential operational aspects: confirmation, availability, pricing, and content constraints. It does not describe the response format, but that is not required. Minor omission of media_ids details, but overall sufficient for correct invocation.

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

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

Schema description coverage is only 25% (only confirm is described). The description mentions quote_tweet_id in the endpoint and references text in the context of not inventing it, but does not clarify media_ids or the exact format of text. It adds some value over the schema but does not fully compensate for the low coverage, especially for media_ids.

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 explicitly states 'POST /2/tweets with quote_tweet_id', clearly indicating the action (quoting a post) and the resource. This distinguishes it from sibling tools like x_organic_reply or x_organic_create_post, which have different endpoints and purposes. The title reinforces the purpose.

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

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

The description provides explicit usage constraints: confirm=true is mandatory, and it warns about Enterprise-only availability and potential 403 errors. It also cautions against inventing content. However, it does not explicitly mention alternative tools or when not to use this tool beyond plan restrictions, so it lacks explicit exclusions.

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

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

Beyond annotations, which only set readOnlyHint=false and openWorldHint=true, the description discloses access tiers, success preconditions, pay-per-use costs, confirmation requirements, and content policy guardrails. This is substantial behavioral context that annotations do not provide.

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

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

The description is dense and front-loaded, with every sentence adding relevant operational or policy value. Pricing, success conditions, and usage rules all earn their place without filler.

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

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

For a mutating X API action with no output schema, the description covers the essential invocation context: endpoint semantics, confirmation, access restrictions, and cost implications. It stops short of describing expected response shape or media handling, but the tool remains safely invocable.

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 25%, so the description must compensate. It adds meaning for confirm and in_reply_to_tweet_id, and warns about link costs, but leaves text and media_ids behavior implicit. Partial compensation, not complete.

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

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

The description opens with a specific verb and resource — 'POST /2/tweets as a reply (in_reply_to_tweet_id)', making the tool's core action unmistakable. It also identifies the reply relationship explicitly, which separates it from siblings like create_post, quote, and create_thread.

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 concrete conditions for when this tool is allowed: replies to others succeed only if they @mentioned or quoted you, and self-replies are the intended thread mechanism. It also adds strong anti-spam and link-warning guidance, though it does not explicitly name alternative tools.

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?

Rich behavioral disclosure beyond the minimal annotations (readOnlyHint=false, openWorldHint=true): if upload fails, STOP and do not post a text-only substitute; requires confirm=true; cost details (~$0.015/post, ~$0.20 with links); and 'Warn before posting links.' This fully compensates for the sparse annotations and gives the agent the safety and failure semantics it needs.

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

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

Front-loaded with the core purpose in the first sentence, then terse constraint clauses. Every sentence adds information (failure policy, confirm requirement, access tiers, cost, link warning). Slightly dense given the 17% schema coverage, but nothing is wasted for a composite tool.

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

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

Complete on the behavioral side: failure handling, confirmation, access restrictions, pricing, and link-warning policy are all covered. The main gap is the unresolved media-parameter ambiguity (media vs media_ids vs media_url), which matters for a tool whose entire point is attaching media. No output schema exists, but for a write-only post tool that's acceptable.

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

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

With schema description coverage at only 17%, the description must compensate for undocumented parameters. It adds meaning to confirm ('Must be true') and implies in_reply_to_tweet_id as the reply target, but it never clarifies the semantics of the three overlapping media parameters (media vs media_ids vs media_url) — a real gap for an agent deciding how to attach media. Partial compensation only.

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

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

The description opens with 'Composite: upload media (if given) then reply,' stating a specific verb (reply), resource (tweet), and the composite workflow. This clearly distinguishes it from the sibling x_organic_reply (text-only) and x_organic_upload_media (upload-only). An agent can tell exactly what this tool does 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?

Provides concrete usage conditions: self-serve replies only succeed when @mentioned or quoted, enterprise is unrestricted, and self-replies serve as the intended thread mechanism. It also flags when to warn before links. However, it doesn't explicitly contrast with x_organic_reply or x_organic_upload_media as alternatives, leaving the composite-vs-two-step decision implicit 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?

Beyond the annotations (readOnlyHint=false), the description adds a critical behavioral requirement: confirm must be true and set only after explicit user confirmation. It also indicates the operation is a POST, reinforcing its mutating nature. This adds value beyond the schema, without contradiction.

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 that conveys the endpoint and the crucial confirm requirement. It is front-loaded and free of filler, making it easy for an agent to parse quickly.

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

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

For a simple two-parameter tool with no output schema, the description covers the essential action and the confirm requirement. It omits details like response format, side effects (e.g., public visibility), or prerequisites beyond confirmation, but these are not critical for invocation given the annotations.

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 covers confirm (50%) but not post_id. The description refers to 'the post to repost', which gives context to post_id as the target post. It does not elaborate on format or other details, but it partially compensates for the schema's missing description.

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

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

The description explicitly states the action via the HTTP endpoint 'POST /2/users/:id/retweets' and the tool title 'Repost'. This clearly identifies a repost operation, and the sibling 'x_organic_unrepost' provides contrast, making it unambiguous which tool to use for creating a repost.

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 notes that confirm=true is required after the user names the post, which is a condition for use. However, it does not explicitly contrast with alternatives like unrepost or explain when not to use this tool. The guidance is implicit rather than explicit.

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 signal destructiveHint=true and readOnlyHint=false; the description adds the terminal nature of cancel and the confirmation guard after user naming. It does not describe pause/resume side effects, but the annotation carries the mutating safety profile.

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 clauses deliver the full operational meaning with no filler, and the most important behavioral note (terminal) 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 three-parameter, no-output-schema mutation tool, the description covers the core behavior, safety, and confirmation requirement. It could add how to obtain job_id or post-cancel effects, but nothing essential is missing for selecting and invoking it.

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

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

Schema coverage is 0%, so the description must add meaning, and it does: 'named job id' defines what job_id refers to, the three action values are spelled out, and confirm=true is tied to the user explicitly naming the job. It doesn't discuss the default 'cancel' action, but the schema covers that.

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

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

The description explicitly names the resource ('named job id') and the three actions ('Cancel (terminal), pause, or resume'), which makes the tool's purpose unmistakable and distinguishes it from schedule_list and schedule_create 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 gives a concrete precondition: 'confirm=true after the user named the job,' which tells the agent when it is safe to proceed. It does not explicitly name alternatives, but the action set and job-id target are clear enough to separate this from status/list/create siblings.

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

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

Annotations only say readOnlyHint=false and openWorldHint=false, so the description carries the transparency burden. It discloses that the action is enqueued, that publish_queue is enabled, that the tool must be allowlisted, and that confirm=true gates firing. This goes beyond the annotations without contradicting them.

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 the core action. Every sentence adds operational value: the scheduling constraint, allowlist requirement, no-invention rule, confirmation flow, worker mechanism, and kind definitions. No filler or repetition.

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

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

This is a 10-parameter mutation tool with no output schema and minimal annotations. The description covers the main scheduling path well, but it omits timezone, max_runs, name, and any indication of return behavior. These gaps could lead an agent to produce an incomplete cron or recurring schedule call.

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

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

Schema description coverage is only 30%, so the description must compensate. It usefully maps kinds to their key parameters: once (run_at ISO), every (every_ms), cron (5-field), and explains arguments and confirm semantics. However, it leaves timezone, max_runs, and name undocumented, which matters for a 10-parameter tool with sparse schema descriptions.

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: 'Enqueue a future organic action on AdvisorPPC's queue.' It clearly separates scheduling creation from the sibling schedule_list/schedule_cancel tools, though it does not explicitly name an alternative. It also states the key enabling effect, 'Enables publish_queue so the worker will fire it.'

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

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

The description gives clear functional context: X cannot natively schedule, the tool must be allowlisted, and confirm=true is required only after the user has named the time and copy. It also warns never to invent arguments. However, it does not explicitly say when not to use this tool or point to alternatives like schedule_cancel.

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 and openWorldHint=false, and the description does not contradict them. It adds the scoping detail that it lists AdvisorPPC queue jobs, which is useful context beyond annotations, but it does not disclose any additional behavioral traits such as result limits, ordering, or whether the list is exhaustive. The description is consistent but adds minimal behavioral insight beyond the annotations.

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

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

The description is two short sentences with zero waste. It front-loads the main purpose and scope ('List AdvisorPPC queue jobs') and then adds the filter capability. 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 list tool with one optional parameter, the description covers the essential purpose and filter. It does not describe the return format (e.g., array of job objects) or any pagination, but given the low complexity and lack of an output schema, the description is reasonably complete. An agent can infer the basic behavior from the name and description.

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

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

The single parameter 'status' is documented in the schema with an enum, but the description adds meaning by explaining it is a filter ('Filter by status'). Since schema description coverage is 0%, the description compensates by clarifying the parameter's purpose, even though it does not list the enum values (which the schema already provides). This adds value 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 uses a specific verb 'List' with a clear resource 'AdvisorPPC queue jobs' and clarifies it is 'not X native', which distinguishes it from X-native scheduling tools. This makes the tool's purpose immediately clear and differentiates it from siblings like x_organic_schedule_create and x_organic_schedule_cancel.

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 context by noting the jobs are from AdvisorPPC, not X native, which hints at when to use it versus X-native listers. However, it does not explicitly name alternative tools or specify conditions like 'use this when you need AdvisorPPC job status, use x_organic_scheduler_status for scheduler status'. The guidance is implied but not explicit.

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

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

The description explicitly reveals that the tool can both read ('Get') and mutate ('patch') settings, which is useful given readOnlyHint is only false rather than affirmatively informative. It also adds context that webhook_url is a callback used by Claude/ChatGPT/AdvisorPPC. However, it does not disclose effects of patching, whether partial updates are supported, authentication needs, or what happens when no parameters are supplied.

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 dense sentence with no filler, front-loading the core operation ('Get or patch') before listing the affected fields. Every word contributes to the tool's purpose, and it is appropriately sized for the scope.

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

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

Given there is no output schema and no explicit parameter documentation, the description should clarify the response shape, empty-parameter behavior, and relationship to scheduler setup/status tools. It does none of these, leaving important operational details unresolved. The tool may be functional for an informed agent, but contextually it is incomplete.

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

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

Schema description coverage is 0%, so the description must compensate, but it mostly repeats parameter names without explaining their meaning. It adds only a clue that webhook_url is a digest callback for AI assistants; timezone format, tick_ms units/role, and public_url purpose remain ambiguous. This is insufficient for a tool with four optional 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 uses a clear verb-resource pair ('Get or patch') and enumerates the specific settings involved: timezone, webhook_url, tick_ms, public_url. It is more specific than the title and lets an agent identify this as the settings-management tool among many scheduler siblings. The phrase 'digest webhook_url' is slightly awkward, but the overall purpose is still clear.

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 no guidance on when to use this tool versus alternatives like x_organic_scheduler_setup, x_organic_scheduler_status, or x_organic_schedule_*. It does not state that this is for reading/updating shared scheduler configuration rather than setting up or inspecting schedules. The agent is left to infer usage from the verb phrase 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?

The description discloses meaningful side effects: it starts the in-process worker, writes the job store, and returns paste-ready MCP snippets. The line 'Does not invent posts' is a useful constraint beyond the annotations, which only carry false hints.

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 concise sentences front-load purpose and side effects before the clarifying constraint. There is no filler or redundant repetition of the schema.

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

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

The description provides a solid high-level contract, including side effects and return shape, but omits defaults/behavior for optional parameters and does not clarify whether a no-arg invocation performs a vendor-agnostic default setup. Without an output schema, this is enough to call but not 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?

Only public_url and webhook_url have schema descriptions, and the description does not explain the timezone parameter or default behavior when optional fields are omitted. Vendor choices are listed but not tied to parameter semantics, 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 names a specific action ('Self-configure the AdvisorPPC scheduler'), enumerates target vendors, and describes visible effects (starts worker, writes job store, returns snippets). It is clearly distinguishable from sibling tools like schedule_create or scheduler_status.

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

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

The description implies this is for initial or automated scheduler setup, but it never states when to prefer it over scheduler_settings, scheduler_status, or schedule_create, nor when not to use it. There are no explicit exclusions or alternative routing cues.

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 provide readOnlyHint=true, and the description adds useful behavioral context beyond that: it notes the queue is AdvisorPPC's own because the X API has no native schedule, and it discloses that HTTP mode starts the worker automatically. This gives the agent operational awareness beyond the structured hint.

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 concise sentences with no filler. The first sentence orients the reader with the core resource and the second lists observable data, making it efficient and 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 zero-parameter, read-only status tool, the description is complete: it explains what the tool is, what it shows, why the queue exists, and a relevant behavioral note about HTTP mode. No critical information is missing for an agent to call it correctly.

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

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

The tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description adds no parameter details, but none are 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 clearly identifies the resource as 'AdvisorPPC's own job queue' and specifies the verb 'Shows' plus the exact contents: worker, agents, upcoming jobs, and last runs. This distinguishes it from sibling tools like scheduler_settings and schedule_list, which address different aspects of 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?

The description gives clear context for when to use the tool by enumerating what it displays, making its purpose obvious for status checks. It does not explicitly name alternatives or exclusions, but the scope is well enough defined that an agent can route to it appropriately.

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 and openWorldHint=true, and the description adds useful behavioral context beyond them: it is billed per matching post and should not be run in unbounded loops. This is valuable operational/cost information the structured annotations do not convey. No contradiction with annotations.

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

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

Three short sentences with zero fluff. The first sentence front-loads the endpoint and time window, while the second and third add essential constraints on query ownership and cost.

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 description gives enough for a simple query call, including the last-7-days window and cost warning. However, with no output schema and low parameter documentation, it leaves gaps around default result counts, date/time format expectations, pagination behavior, and what response shape to expect.

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 14%, so the description should compensate for the 7 parameters. It only clarifies the query parameter ('must be the user's'), and says nothing about end_time, start_time, since_id, until_id, max_results, or pagination behavior beyond the schema's own pagination_token note. The low coverage burden is not met.

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?

Description states a specific resource (GET /2/tweets/search/recent) with a clear time scope (last 7 days), and distinguishes it from sibling x_organic_search_users by implying post search rather than user search. 'Query must be the user's' adds a precise scoping constraint.

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

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

It explicitly says the query must be the user's and warns against unbounded brand-watch loops, which tells the agent when this tool is appropriate versus when it should be avoided. It doesn't name alternatives like x_organic_search_users, but the endpoint and 'recent' scope make the intended use fairly clear.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds useful anti-hallucination context by warning not to invent people to follow, but it does not disclose behavior like pagination limits, result shape, or rate considerations.

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

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

The description is a single front-loaded sentence that states the endpoint and the key behavioral constraint with no wasted words. It earns its place.

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

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

This is a minimally viable definition for a simple read-only search tool: the endpoint, required query, and anti-fabrication rule are clear. However, without an output schema, it does not explain what results look like, and it lacks guidance for pagination or when to use alternative lookup tools.

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

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

Schema description coverage is only 33%, so the description must compensate. It adds meaningful guidance for the query parameter, but max_results is left to its name and schema bounds, and pagination_token is only described via the schema, not the tool description.

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

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

The description clearly identifies a specific operation: GET /2/users/search to search users. It is not a tautology and is meaningfully distinct from sibling tools like lookup_user or lookup_users, though it does not explicitly call out those differences.

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 instruction 'Query must be what the user asked to find' implies when to use the tool, but there is no explicit guidance about when to prefer this over siblings such as lookup_users or search_recent. No alternatives or exclusions are mentioned.

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 indicate a write operation (readOnlyHint=false) and side effects (openWorldHint=true). The description adds meaningful context: confirmation requirement, anti-spam guardrails, and the single-conversation constraint. It fully discloses the operational behavior beyond the annotations, with no contradictions.

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, every sentence carries operational weight, and the core action is stated first. No fluff or repetition; it efficiently packs recipient options, confirmation, media linkage, and spam restrictions into a few lines.

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

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

With no output schema, the description should explain expected outcomes or errors, but it doesn't mention return values, failure behavior, or rate limits. It covers prerequisites and constraints well, but for a 6-parameter write operation, missing response semantics leaves a gap for the agent to guess.

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

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

Schema coverage is only 33%, so the description must compensate. It clarifies that participant_id and username are alternative recipient identifiers, dm_conversation_id is an existing conversation, and media_id is optional from upload_media. It also explains confirm's requirement. Not every parameter is detailed (e.g., text is obvious), but the description adds meaningful semantics for the ambiguous ones.

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 ('Send'), a clear resource (a direct message to a named recipient or existing conversation), and distinguishes itself from siblings by being the DM-specific tool. It also scopes the action to a single DM with no bulk, which prevents confusion with posting tools.

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

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

The description gives explicit conditions: requires confirm=true after an explicit ask, never invent copy, one recipient, no bulk unsolicited DMs. It also mentions the optional media_id from x_organic_upload_media. While it doesn't explicitly contrast with public replies, it provides enough contextual rules to guide appropriate 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?

Annotations already indicate readOnlyHint=false, so the mutation nature is known. The description adds no extra context about side effects, error handling, authentication requirements, or irreversibility. It only restates the HTTP method, which is already implied by the annotation.

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 extremely terse, consisting of a single endpoint string. It is not structured as a sentence and lacks any explanation or front-loading of purpose. It is under-specified rather than efficiently concise.

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 one undocumented parameter, no output schema, and minimal annotations, the description is wholly inadequate. It omits essential context such as what the parameter represents, expected behavior, and any usage notes.

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

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

The schema has one parameter post_id with no description and the description provides no explanation of what post_id refers to. Since schema description coverage is 0%, the description fails to compensate by explaining the parameter's meaning or format.

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 the HTTP method and path, which clearly indicates a delete operation on bookmarks. However, it is just the endpoint string and does not explicitly say 'removes a bookmark for the authenticated user.' The title 'Remove bookmark' reinforces the purpose, but the description itself is minimal and not a natural-language explanation.

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 is given on when to use this tool versus alternatives like x_organic_bookmark or x_organic_list_bookmarks. There is no mention of the intended scenario or any exclusions.

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

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

The readOnlyHint=false annotation already indicates mutation, and the DELETE method in the description adds more specificity by naming the resource being affected. However, the description does not disclose auth requirements, idempotency, side effects of unliking when no like exists, or how openWorldHint=true behaves. It adds only a thin layer of behavioral detail beyond the annotations, so the description carries an incomplete but non-contradictory 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?

The description is extremely short and contains no filler, making it easy to scan. However, it is more of an API endpoint signature than a prose explanation, so its brevity is structural rather than informative. Every word earns its place, though the description could have used the space to clarify the ambiguous parameter.

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?

This is a simple one-parameter tool with no output schema, so complex return value documentation is not required. Yet the description omits any usage context and leaves the post_id semantics unexplained against a 0% schema coverage. An agent would struggle to know whether to pass a post ID or a tweet ID and whether the endpoint path should be interpolated differently, making the definition incomplete for a tool that should be very simple.

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

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

Schema description coverage is 0%, so the description carries the full burden of explaining the post_id parameter, but it only provides endpoint placeholders like :tweet_id. The schema requires post_id, while the description references tweet_id separately, leaving the mapping ambiguous. There is no explanation of what post_id represents, how it maps to the URL path, or whether the user id is also required.

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 concrete HTTP verb and resource: DELETE on /2/users/:id/likes/:tweet_id, which clearly identifies the action of removing a like. It is also clearly distinct from sibling x_organic_like because one tool adds a like and the DELETE verb is explicit here. No agent could confuse this tool with a post deletion or repost action after reading the endpoint.

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 no guidance about when to use that tool versus alternatives. It does not mention whether this should be used for unliking a post, unbookmarking, deleting a post, or any prerequisite states such as requiring an existing like. Usage context is entirely left to inference.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the DELETE method and confirm requirement add modest context. The description does not explain side effects beyond the endpoint, such as whether the original post is unaffected or what happens on a non-existent repost. It does not contradict annotations.

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

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

The description is extremely short and front-loaded, with no filler. Both sentences carry necessary information: the exact endpoint and the confirmation requirement.

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 action with destructive annotations, the description is minimally adequate. It lacks a clear statement that this removes the authenticated user's repost of a given post and does not explicitly map post_id to the path's tweet_id. No output schema exists, so some behavioral detail would help.

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

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

Schema description coverage is 50%, with confirm already well described in the schema. The endpoint path provides a weak hint that post_id corresponds to tweet_id, but the description does not otherwise clarify parameters. It mostly duplicates the confirm requirement rather than adding new semantic value.

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

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

The description identifies a specific verb (DELETE) and resource (retweets/:tweet_id), and the title 'Undo repost' makes the intent clear. It is distinguishable from siblings like x_organic_repost by the DELETE method and retweet resource. However, it relies on API-path shorthand rather than a plain-language statement of what is removed.

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 no guidance on when to use this tool instead of alternatives like x_organic_delete_post or x_organic_repost. The only usage-related instruction is 'Requires confirm=true', which is a precondition rather than a when-to-use or when-not-to-use guide.

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

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

The description goes far beyond the annotations by disclosing the two upload paths (simple vs. chunked INIT/APPEND/FINALIZE), the >5MB threshold, the need to poll STATUS, the 'exactly one of media_url or media' constraint, and the failure behavior ('STOP, do not substitute'). This is rich behavioral disclosure consistent with the false readOnly hint.

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 information-dense, with the purpose front-loaded and every sentence contributing a distinct guideline. It covers use context, protocol branching, exclusion, parameter constraint, and failure handling without wordiness.

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 description is detailed about the upload flow, but with no output schema it omits what the tool returns—most importantly a media_id needed by sibling post/DM tools—and doesn't explain how the uploaded media should be consumed by downstream tools. This is a meaningful gap for an agent trying to chain calls correctly.

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

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

Schema description coverage is only 33%, so the description must compensate. It clarifies the core mutual exclusivity of media and media_url, and connects file-size/type behavior to the media parameter. It does not explain every nested field like data or encoding, but the schema already requires data and defaults encoding, so the added semantics are meaningful.

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

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

The description states a specific action ('Upload an image or video') with a clear resource scope ('for an organic post... or a DM') and names the exact media types involved. This clearly distinguishes the utility from sibling post/DM actions and leaves no ambiguity about what the tool does.

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

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

It gives strong context for when to use this tool: uploading media for organic posts or DMs, with an explicit exclusion for ads ('Never amplify_video'). It does not explicitly name sibling alternatives like x_organic_create_post or x_organic_send_dm, but the purpose and media workflow are clear enough to guide selection.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces this with GET. It adds the useful context that user_id should be sourced from lookup/me, but it does not disclose behavior such as whether replies/retweets are included by default, pagination behavior, or response shape. With annotations covering the safety profile, this is adequate but not rich.

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 compact line that front-loads the HTTP method and resource, then gives the two most important calling hints. Every word 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 read-only, zero-required-parameter timeline fetch, the description plus schema cover the essential invocation details: endpoint, user_id source, optional exclude, max_results bounds, and pagination token. No output schema exists, so return-shape details are not strictly expected, though noting the default inclusion of replies/retweets would make it slightly more complete.

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

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

Schema coverage is 75%, and the schema already documents exclude, user_id, pagination_token, and max_results bounds. The description adds only that user_id comes from lookup/me and that exclude is optional, while max_results and pagination are left to the schema. This is a modest value-add over the schema.

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

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

The description names a concrete endpoint (GET /2/users/:id/tweets) and the resource ('User post timeline'), and tells the agent to pass user_id from lookup/me. This clearly identifies the tool as fetching a user's posts, but it does not explicitly differentiate it from siblings like my_timeline or lookup_posts.

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

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

The description gives operational guidance: pass user_id from lookup/me and treats exclude=replies,retweets as optional. However, it never states when to prefer this tool over sibling timeline/search/list tools, so usage context is implied rather than explicit.

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