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?

The description goes well beyond the annotations by disclosing confirmation requirements, pay-per-use costs, link-warning obligations, and the absence of native scheduling. It also warns against inventing content and clarifies media type limits. This is exactly the kind of behavioral context an agent needs before invoking a paid, user-visible 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?

Every sentence earns its place: endpoint, content faithfulness, confirmation, cost, link warning, scheduling limitation, and media caps are all packed in without filler. The most critical operational constraints are front-loaded, making the description easy 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 paid, user-visible mutation with no output schema and limited annotation support, the description covers the most critical operational risks: confirmation, cost, content provenance, link warnings, scheduling, and media limits. It falls slightly short only by not explaining reply_settings semantics or the expected return shape, but these are secondary for correct invocation.

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

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

Schema coverage is only 25%, so the description must compensate. It adds meaning for text (use only user-supplied copy, never invent) and media_ids (from x_organic_upload_media; up to 4 photos, 1 GIF, or 1 video). However, reply_settings is left entirely undocumented in both schema and description, leaving one parameter under-specified.

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 operation as creating a single post via the specific endpoint POST /2/tweets, with concrete content constraints. It is distinct from sibling tools like x_organic_create_thread, x_organic_reply, and x_organic_quote, though it does not explicitly name those alternatives.

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 conditions for use: only after an explicit named ask, with confirm=true, and after warning the user about link costs. It also states that X API has no native scheduling, so agents should not fake a queue or publish time. It does not explicitly contrast with thread/reply/quote tools, but the context is otherwise strong.

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

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

Annotations state readOnlyHint=false and openWorldHint=true, but the description adds substantial behavioral detail: the exact composite posting sequence, partial-failure behavior ('STOP and return what already went up'), per-post cost estimates, the confirm requirement, link-warning duty, and the absence of native scheduling. This goes far beyond what annotations alone convey and contains no 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?

Each sentence earns its place: composite mechanics, content fidelity, confirm requirement, failure handling, cost, link warning, and scheduling limitation. The most important purpose statement is front-loaded, and the description remains compact given the number of critical constraints it covers.

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 mutation tool with no output schema, the description covers the full invocation contract: how to structure the thread, what content to use, the confirmation gate, failure semantics, cost implications, link warning, and scheduling impossibility. The only minor gap is reply_settings, but its enum values are self-explanatory and the schema carries that information.

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 `confirm` is described). The description compensates meaningfully for `posts` by specifying that it must be the user-supplied array and that no posts may be invented, and for `confirm` by clarifying it is required once for the whole thread. However, `reply_settings` is left completely unexplained in both schema and description, and media handling is only implied.

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 composite behavior: 'publish the first post, then chain the rest as replies (in_reply_to of the previous).' This clearly identifies the resource (a thread of posts on X) and the verb (create/publish), and the composite nature distinguishes it from single-post siblings like create_post or reply.

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 operational guidance: use only user-supplied copy, require confirm=true once, stop on later-post failure, warn before posting links, and never simulate scheduling because X has no native schedule. It does not explicitly name the sibling single-post tools as alternatives, but the composite distinction and the scheduling exclusion provide strong contextual usage direction.

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

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

Annotations 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?

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.