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

With no annotations provided, the description carries the full burden for behavioral disclosure. It adds valuable safety context ('read-only, no DB') and source information (recent timeline), but omits output format, error conditions, and edge cases such as insufficient data. This is a modest but not comprehensive 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 remarkably concise, consisting of two sentences that front-load the core purpose followed by contextual safety/source details. Every clause contributes essential information, with minimal wasted words.

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

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

For a moderate-complexity analysis tool with no output schema, the description covers the primary purpose and safety profile but leaves gaps around return values, minimum-data requirements, and how 'best-hours' is determined. The parameter schema fills parameter details, so the description's brevity is partly justified but not fully complete.

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

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

Schema description coverage is 100%, so the schema fully documents all four parameters. The description adds no additional parameter-level meaning beyond what the schema already provides, earning the baseline score of 3.

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 a specific action ('Analyze') targeting a defined resource ('when you post vs average lifetime impressions by hour of day'). It distinguishes this tool from sibling analytics or post-management tools by focusing on posting-time analysis, making its purpose unambiguous.

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

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

The description provides contextual usage cues ('Derived from your recent timeline') but does not explicitly state when to prefer this tool over alternatives or mention exclusions. Usage is implied rather than directly guided, with no comparison to sibling tools like get_x_post_metrics.

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

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

With no annotations, the description carries the transparency burden. It discloses the approval action and the system rule that only approved drafts can be sent, adding useful context. However, it does not discuss reversibility, possible side effects, or return behavior, leaving gaps in behavioral 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 two concise sentences with no unnecessary words. The action is front-loaded, and each sentence contributes essential information about the purpose and usage.

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

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

Given it is a simple one-parameter tool with no output schema, the description captures the core behavior and the key precondition. It could optionally mention whether approval is reversible or what happens after approval, but current information is 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?

The schema documents the single 'id' parameter with 100% coverage, so the baseline is 3. The description does not add any parameter-specific information beyond the schema, providing no additional 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 begins with 'Mark a DM draft approved', which clearly identifies the verb, resource, and DM-specific scope, distinguishing it from sibling tools like approve_draft and approve_retweet_draft. The second sentence 'Only approved drafts can be sent' adds further clarity about the tool's role in the workflow.

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 provides a precondition: 'Call only after the user explicitly reviewed the message', which is clear when-to-use guidance. However, it does not mention alternatives or exclusions, such as when to use reject_dm_draft instead, stopping short of a full 5.

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

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

No annotations are provided, so the description carries the full burden. It adds a key prerequisite ('after the user has explicitly reviewed and approved') and a system rule ('Only approved drafts can be published'). However, it does not disclose whether the operation is reversible, what happens if the draft is already approved, or any error conditions, leaving some behavioral gaps.

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

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

The description is two concise sentences with a clear action-first structure. Every sentence provides meaningful context: the first defines the action, the second adds a usage condition and system implication. No unnecessary words.

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

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

For a simple state-change tool with one parameter and no output schema, the description covers the essential aspects: what it does, when to call it, and why it matters. It could add details about edge cases or effects on the draft object, but this is a low-complexity tool where the description is largely sufficient.

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

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

The input schema already fully describes the single 'id' parameter as 'Draft id', and the description does not add any additional meaning or context for the parameter. With 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description clearly states the verb ('Mark') and resource ('draft as approved'), which is specific and distinguishes it from siblings like reject_draft and publish_draft. It is unambiguous about the action being an approval state change.

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

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

The description gives a clear condition: 'Only call this after the user has explicitly reviewed and approved the draft text.' It also implies a relationship with publish_draft by noting that only approved drafts can be published, which helps the agent sequence actions. It does not explicitly mention alternatives like reject_draft, but the context is sufficient for most scenarios.

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

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

No annotations are provided, so the description carries the transparency burden. It discloses that the tool marks the draft as approved and that approval is required for execution. The safety guideline about calling only after user review adds valuable behavioral context. However, it omits details about permissions, reversibility, or other side effects.

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

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

Three short sentences, front-loaded with the primary action. Each sentence adds distinct information: the action, the system rule, and the usage condition. No redundancy or unnecessary words.

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

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

For a simple one-parameter tool with no output schema, the description covers the primary action, a key system rule, and a usage condition. It could mention the counteraction (reject_retweet_draft) or the draft lifecycle, but it is sufficiently complete for an agent to select and invoke correctly.

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

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

The single parameter 'id' is fully described in the schema as 'Retweet draft id.' The description adds no additional parameter semantics. With 100% schema coverage, the baseline score of 3 applies.

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

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

The description clearly states 'Mark a retweet/undo draft approved' with a specific verb and resource. It distinguishes from sibling tools like approve_draft and approve_dm_draft by explicitly scoping to retweet/undo drafts, making the purpose unambiguous.

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

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

Provides an explicit condition: 'Call only after the user explicitly reviewed the action.' Also notes 'Only approved drafts can be executed,' which implies the tool is a prerequisite for execution. It does not explicitly name alternative approval tools, but the context is clear enough.

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

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

With no annotations provided, the description fully carries the transparency burden. It discloses the search scope (niche/keywords, not global trends), filtering behavior (removes spam/near-duplicates), output composition (scored topics, sample tweets, engagement numbers, demand signals, timing recommendation), and important guardrails (do not fabricate engagement numbers, ground claims in sample tweets). This goes well beyond a basic read-only declaration and gives the agent clear expectations.

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 longer than typical but front-loaded with the primary purpose and then systematically explains outputs and post-usage guidance. Every sentence serves a purpose, and the structure is logical (what → how → what to do next → warnings). It is slightly verbose but appropriate for a tool with no annotations or output schema, as it must convey necessary 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?

Given the tool has no output schema and no annotations, the description must explain return values and safety/behavioral aspects. It does this thoroughly: it names the specific output components (trendingTopics, painPointSignals, sample tweets, engagement numbers, timing recommendation) and explains how the results should be used, including warnings against fabrication. This makes the tool usable for an AI agent without additional external context.

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

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

Schema description coverage is 100%, so the schema already documents all 6 parameters. The description adds minimal semantic value beyond mentioning 'niche/keywords' and 'product's name/description/audience' in the context of post-call content generation. It does not provide additional meaning or syntax for the parameters, so it stays at the baseline score for high schema coverage.

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

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

The description clearly identifies the tool's purpose: discover trending topics on X scoped to a niche, with specific verbs ('Discover', 'Searches') and a clear resource (X posts). It explicitly distinguishes itself from X's generic global trending list and from sibling tools, which are all content posting/draft/DM actions, making it unique as a trend research tool.

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

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

The description provides strong usage context: it is meant to be used before writing content, and explicitly instructs what to do after calling it ('use the returned trendingTopics... to write natural, platform-appropriate content'). It also notes what the tool does not do (does not generate content itself, does not use X's global trending list). However, it does not explicitly state when not to use it or name alternative tools, though no direct alternative exists among siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the draft lifecycle (not sent until approved), the required addressing modes, and the one-attachment limit, which are meaningful behaviors beyond what the input schema specifies.

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 concise sentences, each covering a distinct aspect: purpose, requirements, and workflow. No redundant information; it is well-structured and front-loaded.

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

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

Given the tool has 8 parameters and no output schema, the description covers the essential context: what it does, how to address a recipient, the draft approval flow, and media limits. It doesn't detail group conversation setup, but the schema provides that information, making the description adequate for an agent to decide when to use it.

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

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

Schema descriptions cover all parameters (100%), so the baseline is 3. The description adds cross-parameter semantics by explaining the alternatives (recipientId or recipientUsername or conversationId) and the media attachment constraint, which is not immediately obvious from individual property descriptions.

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

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

The description clearly states 'Create a draft direct message' with a specific verb and resource. It distinguishes itself from sibling tools like create_draft and create_retweet_draft by explicitly scoping to direct messages.

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 usage prerequisites: requires recipientId, recipientUsername, or conversationId for existing threads. It also clarifies the workflow by noting the draft is NOT sent until approved and send_dm_draft is called, which helps an agent understand when to use this tool versus other DM draft operations.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly states the draft is not published until approved and explicitly published, and it details the non-obvious link-handling rule, including the opt-out flag. It does not mention authentication or rate limits, but the key safe behavior (no immediate publishing) and the link constraint are well disclosed.

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

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

The description is a single, well-organized paragraph that front-loads the purpose in the first sentence, then lists supported features, states the critical rule, and explains the safety behavior. Every sentence provides necessary information without redundancy. The use of 'RULE' in caps draws attention to the most important constraint.

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 10 parameters and a nested poll object, the description gives sufficient context for correct invocation by explaining the workflow (draft, approve, publish) and the key behavioral rules. It does not describe return values, but no output schema exists, and the main purpose is to guide selection and invocation, which it does well. It could mention what the response contains (e.g., draft ID), but the description is otherwise 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 100%, so the baseline is 3. The description adds value beyond the schema by emphasizing the critical rule that URLs must go in parts[1+] and that allowLinksInMainPost should only be true on explicit user request. It also summarizes the supported features and notes the 'text must equal parts[0]' constraint, reinforcing relationships already present 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 verb and resource: "Create a draft social post for a channel (currently only "x")". It distinguishes from sibling tools by framing the action as creating a draft, which is later approved and published by other tools. The scope (channel 'x') and feature list (text, threads, polls, etc.) are explicit.

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

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

The description provides strong contextual guidance by noting that drafts are "saved locally and NOT published until approved and then explicitly published", which clarifies the tool's role in the workflow. It also includes the rule about avoiding links in the main post. However, it does not explicitly name alternatives like update_draft or publish_draft, but the workflow description implies when this tool is appropriate.

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

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

With no annotations, the description carries the transparency burden. It discloses the key behavioral trait that the action is not executed until approved, and that retweet_post or undo_retweet must be called later. It also gives the format for the post id. It does not cover auth or rate limits, but for a draft-creation tool, the non-execution trait is the critical behavioral 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 two sentences: the first states the purpose, the second adds the critical non-execution note and the id format. Every sentence earns its place; no filler. Front-loaded with the main verb and resource.

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 draft-creation tool with two parameters, the description covers the core function, the approval workflow, and the id format. It does not explain return values, but an output schema is absent so this is not strictly required. It slightly lacks explicit mention of how the draft will later be managed (e.g., via list_retweet_drafts), but the sibling tool set implies this. Overall, it is sufficiently complete for a low-complexity 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% (both parameters have descriptions). The description adds value by specifying the exact format for tweetId: 'Pass the numeric post id from an X URL (e.g. .../status/1234567890).' This reinforces and clarifies the schema description, offering a concrete example that aids correct invocation.

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

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

The description uses a specific verb-resource pair: 'Create a draft retweet or undo-retweet action.' This clearly distinguishes it from sibling tools like retweet_post (which executes) and create_draft (which creates a regular draft). It also specifies the resource (retweet/undo-retweet) and outcome (draft).

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 'NOT executed until approved and retweet_post or undo_retweet is called,' implying this tool is used to stage an action for later approval, and explicitly mentions the subsequent execution tools. It does not explicitly name alternatives like retweet_post/undo_retweet as direct options, but the workflow context is clear. It also provides the URL format for the tweetId parameter.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It clearly states the destructive effect (deletes live posts) and the side effect on the local draft (marks as deleted). It also covers edge cases. It could mention irreversibility, but the key behaviors are transparently disclosed.

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

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

The description is two sentences with no wasted words. The primary action is front-loaded, followed by scope, edge cases, and constraints. Every sentence contributes to understanding the tool's purpose and behavior.

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

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

For a destructive mutation tool with one parameter, no output schema, and no annotations, the description is complete. It explains what the tool does, when it applies, and the expected side effects. The lack of an output schema is acceptable as return values are not critical for a delete operation.

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% for the single parameter 'id' with description 'Draft id.' The tool description adds no additional meaning beyond the schema, such as format or constraints, so the baseline score of 3 is appropriate.

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

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

The description clearly states the primary action ('Delete every live post id recorded on a draft') and the secondary action ('mark the local draft as deleted'), making the tool's purpose unmistakable. It also specifies the scope (root and thread replies) and distinguishes it from siblings like edit_published_draft and publish_draft.

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

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

The description provides clear context on when the tool is appropriate, stating it works 'whenever live ids are recorded' and lists specific scenarios (published drafts, partial publishing failures, corrupt/legacy records). It also notes the limitation 'Own posts only.' While it doesn't explicitly name alternative tools, the implied use case is clear.

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

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

With no annotations, the description fully discloses behaviors: creates new post id, re-attaches media/quoteTweetId, enforces link rules, and notes limitations. This provides comprehensive insight into side effects and prerequisites beyond basic schema info.

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 but efficient, with every sentence conveying a distinct constraint or behavior. It front-loads the core purpose, then lists limitations and rules without redundancy. Appropriate length for a tool with this complexity.

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 covers essential context: method, prerequisites, limitations, exclusions, and special rules. It omits return value details, but since there is no output schema, some ambiguity remains. Still, for tool selection and invocation, it is sufficiently 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 descriptions cover 100% of parameters, so baseline is 3. The description adds context about the link rule and allowLinksInMainPost defaulting to the draft's stored flag, but this is marginal beyond the schema. It does not significantly enhance parameter understanding.

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

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

The description clearly states the action: 'Edit the root post of a published draft' with a specific verb, resource, and scope. It distinguishes itself from siblings like update_draft (pre-publish edits) and delete_published_draft by focusing on published drafts and the root post.

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 explicit context: requires X Premium, edits limited, only thread root edited, polls/community posts cannot be edited. It implies when to use (for published drafts) but does not explicitly name alternative tools. Exclusions are clear, but no direct 'use X instead' guidance.

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

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

With no annotations, the description carries the full burden. It only states 'fetch', implying a read-only operation, but does not disclose potential side effects, authentication requirements, error behavior, or return format. No annotations are present, but the description adds minimal behavioral 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 a single, concise sentence with no wasted words. It front-loads the core action and resource, making it immediately clear.

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

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

The tool is simple (one parameter, no output schema), but the description lacks context on return format, error cases, or relationship to sibling tools. It is minimally adequate for a fetch operation but does not fully flesh out the expected behavior.

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% with the 'id' parameter described as 'DM draft id'. The description's 'by id' adds no new semantic information beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description uses a specific verb 'fetch', identifies the resource as 'a single DM draft', and specifies the retrieval method 'by id'. This clearly distinguishes it from siblings like 'list_dm_drafts' and 'get_draft'.

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 provided on when to use this tool versus alternatives. It lacks an explicit mention of using it for individual DM draft retrieval as opposed to 'get_draft' for regular drafts or 'list_dm_drafts' for multiple DM drafts.

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

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

With no annotations, the description carries the full burden. The verb 'Show' clearly indicates a read-only operation, which is transparent. However, it does not disclose whether the call itself consumes rate limits, any authentication requirements, or how 'local' usage is determined, leaving some behavioral traits implicit.

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 efficient sentence that immediately states the action and resource, followed by helpful specifics. No words are wasted, and the information is front-loaded.

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

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

Despite having no output schema or annotations, the simple zero-parameter nature of the tool is well-served by this description. It covers the purpose and lists the key data points, though it stops short of specifying the exact output format or units, which would be useful for parsing the response.

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

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

The tool has zero parameters, and the schema correctly reflects that. The description adds no parameter information, but none is needed. For a zero-parameter tool, the baseline is 4, and the description adequately supports this.

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

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

The description uses the specific verb 'Show' with the resource 'local DM send rate limits' and details the exact metrics (hourly, daily, min interval). This clearly distinguishes it from sibling DM tools, which focus on sending, drafts, and inbox management rather than rate limits.

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 tool should be used for checking DM rate limits and current usage, but it does not explicitly state when to use it or provide exclusions/alternatives. There are no sibling rate-limit tools, so the context is inferred rather than stated.

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

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

No annotations are provided, so the description carries the full burden. 'Fetch' implies a read operation, but it does not state whether the tool modifies anything, what it returns, or behavior on missing ids. Important behavioral traits like 'does not modify' or 'returns the draft object' are left implicit.

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 brief and front-loaded, containing only one sentence with no filler. The word 'single' adds slight redundancy with 'by id' but does not harm clarity. It is concise and effective for the simple operation.

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

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

The tool is a simple get-by-id operation with one parameter, so the description is relatively adequate. However, without an output schema or annotations, it does not explain what is returned or how errors are handled. It is not fully complete but serves as a minimal viable description.

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

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

Schema coverage is 100% and the 'id' parameter is described as 'Draft id.' The description adds 'by id' which reinforces but does not go beyond the schema. No additional meaning is provided beyond what the schema already documents, so the baseline score of 3 applies.

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

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

The description clearly states the action ('Fetch') and resource ('a single draft by id'), distinguishing it from sibling tools like list_drafts (plural) and update_draft (mutation). The tool name and title align, and the scope is explicit.

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

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

The description implicitly guides use for retrieving one specific draft by id, but it does not explicitly mention when not to use it or mention alternatives like list_drafts for multiple drafts. The single-by-id phrasing suggests the use case, but no exclusions or alternative 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?

No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It simply says 'Fetch', which implies a read-only operation, but it does not explicitly state that it makes no modifications, nor does it mention any permissions, errors, or return behavior. For a tool with no annotations, more explicit disclosure is expected.

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 that immediately states the action and target. There is no fluff, and all words contribute to the meaning.

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

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

For a simple get-by-id tool with one parameter, the description is mostly complete. It tells you what it does and the key scoping (retweet/undo draft). With no output schema, it doesn't describe the return value, but for a fetch operation the return is implied. Minor gap around clarifying what an 'undo draft' is, but 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?

The schema has 100% coverage for the single 'id' parameter with description 'Retweet draft id.' The description's 'by id' adds no additional meaning beyond what the schema already provides. Baseline of 3 is appropriate since schema does the heavy lifting.

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

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

The description clearly states the tool's function: fetching a single retweet/undo draft by id. It uses a specific verb ('Fetch') and resource ('retweet/undo draft'), and distinguishes from sibling tools like 'get_draft' or 'get_dm_draft' by specifying the retweet/undo context.

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 usage is implied: use this when you have a specific retweet/undo draft id and need its details. However, there is no explicit contrast with alternative tools (e.g., 'get_draft' for regular drafts) or mention of when not to use it. The sibling list provides context, but the description itself gives no direct guidance.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It states the connected case but not what happens when not connected (e.g., returns null, false, or error). This is a meaningful gap for an agent.

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

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

A single, well-structured sentence provides all essential information without redundancy. Every clause earns its place.

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

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

Without an output schema, the description should detail return behavior. It mentions returns for the connected case but omits the unconnected case, leaving ambiguity. For a simple tool this is a minor gap, but more clarity would improve completeness.

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

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

The tool has zero parameters, so the schema is trivially complete. The description adds no parameter details, but none are needed. Baseline for 0 params is 4.

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

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

The description uses the specific verb 'check' and states the resource (MCP server connection to X account) and the return value (username and id). It clearly distinguishes from sibling tools by focusing on connection status rather than draft operations.

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 usage: use this tool to verify connectivity and get account details. It does not explicitly exclude alternatives, but sibling tools are clearly unrelated, so the intended context is evident.

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

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

With no annotations, the description explicitly declares read-only behavior, absence of local persistence, and the specific external endpoint. It also hints at alignment with x.com analytics. It omits auth requirements and rate limits, but for a read-only analytics tool the core safety profile is well covered.

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

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

Two sentences that are dense with specific details: endpoint, data types, timezone alignment, and side-effect warnings. No filler or redundancy; front-loaded with action and resource.

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?

No output schema exists, so the description should indicate return values; it does so by listing impressions, engagements, totals, and top posts. It also notes timezone alignment. It doesn't mention auth prerequisites or behavior for empty windows, but for a read-only summary with 4 optional params it is reasonably 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 descriptions cover 100% of parameters, so baseline is 3. The description adds contextual meaning for 'days' (calendar-day) and 'topPosts' (top posts), but doesn't directly explain each parameter's syntax or format beyond the schema.

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

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

The description clearly states the tool summarizes an X account using GET /2/tweets/analytics, listing specific outputs (impressions, engagements, period totals, top posts). It distinguishes from sibling tools like get_x_post_metrics (post-level) and get_x_account (account details).

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

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

The description gives clear context: read-only, no local DB, aligned with x.com account analytics, but does not explicitly mention when to prefer this over siblings or list alternatives. No exclusions are stated, but the read-only nature is a strong usage signal.

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

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

With no annotations provided, the description carries the transparency burden. It states 'Read-only,' which is a meaningful behavioral disclosure, and 'lifetime public metrics' clarifies the scope (only public, lifetime data). It also lists the exact metrics returned, adding value beyond the tool name and schema. It does not cover rate limits or error behavior, but for a simple read-only fetch, this is adequate.

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, well-structured sentence that front-loads the primary action and resource, then lists the specific metrics and constraints. Every word adds value, and there is no redundancy 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 tool with one parameter, no output schema, and no annotations, the description is sufficiently complete: it specifies the operation, the data returned, the cardinality limit, and the read-only nature. It could add error handling or format details, but the low complexity and clear sibling context make this adequate.

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 100% of the single parameter with a description ('Post ids to look up (max 100)'). The tool description reiterates 'up to 100 post ids' but adds no additional semantic meaning beyond what the schema already provides. The baseline of 3 applies because the schema does the heavy lifting.

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

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

The description starts with a specific verb 'Fetch' and clearly identifies the resource: 'lifetime public metrics (impressions, likes, reposts, replies, quotes, bookmarks) for up to 100 post ids.' This fully distinguishes the tool from sibling tools, which focus on drafts, accounts, DMs, and retweets, not post metrics.

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 usage by specifying the exact purpose and limits ('up to 100 post ids'), and the 'Read-only' tag indicates it is a safe lookup operation. However, it does not explicitly state when not to use it or mention alternative tools for other metric types, though no obvious alternative exists among 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?

No annotations are provided, so the description carries the full burden. It states 'Read' (no side effects) and 'recent' (temporal scope), adding some transparency. However, it does not disclose ordering, pagination, or other behavioral traits like what happens with invalid IDs or how maxResults interacts with 'recent.' These gaps make the transparency adequate but incomplete.

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

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

The description is a single, front-loaded sentence with no filler. It quickly communicates the action, resource, and scope. Every word contributes value, making it exceptionally concise and well-structured.

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

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

The tool is simple with only two parameters (one required), no output schema, and no nested objects. The description covers the core purpose and scope, and the schema covers all parameters. Minor omissions like return format and pagination are not critical for this tool's complexity, so the description is mostly complete with only minor gaps.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds the phrase 'by conversationId' which reinforces the role of conversationId, but it provides no new meaning beyond the schema. It does not explain how maxResults affects results, which is already in the schema. Thus the description adds marginal value 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 clearly states the action ('Read'), resource ('DM events'), and scope ('in a conversation by conversationId'). It also distinguishes from sibling tools by specifying per-conversation and supporting both group and 1:1 threads, which differentiates it from broader tools like list_dm_events.

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 makes the usage context clear: use it when you have a conversationId and need recent events for that specific conversation. It does not explicitly mention alternatives or when not to use this tool, but the context is unambiguous and does not require 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?

No annotations are provided, so the description carries the burden of disclosing behavior. 'List' implies a read-only operation, and 'locally stored' adds storage context, but the description does not mention return format, ordering, or whether deleted statuses are excluded by default. For a simple listing tool this is acceptable but not richly transparent.

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

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

A single, front-loaded sentence conveys the resource, the local-storage qualifier, and the optional filter. There is no wasted wording or 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?

The tool is simple: one optional parameter, no output schema, and no nested objects. The description covers the core purpose and filtering capability, which is sufficient for a list operation. It does not describe the returned fields, but that is not a significant gap given the tool's low complexity.

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

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

The input schema has 100% description coverage with a clearly described enum-constrained status parameter. The description merely reiterates the optional filter, adding no new semantic detail beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description uses a specific verb ('List') and explicitly identifies the resource as 'locally stored DM drafts', making it clear this is about DM drafts specifically. This distinguishes it from sibling tools like list_drafts and list_dm_inbox, and the optional status filter is also mentioned.

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

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

The description provides clear context: it lists DM drafts that are locally stored and supports an optional status filter. It does not explicitly name alternatives or exclusions, but the DM-specific naming makes the intended usage clear versus the general list_drafts or list_dm_inbox.

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

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

With no annotations, the description carries full behavioral disclosure. It discloses ordering (newest first), maximum limit (up to 100), and the dm.read scope requirement. However, it does not detail pagination behavior beyond the limit, nor what constitutes a DM event.

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 efficiently captures the core purpose, constraints, and auth requirement. Every element 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 tool with no output schema, the description covers essential behavior: scope, ordering, limit, and auth. However, it doesn't describe the event structure or how the two participant identifiers interact, which could cause usage questions. Overall, it is reasonably complete given the tool's simplicity.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it only reinforces the max of 100 which already exists in maxResults. It does not clarify the relationship between username and participantId, but the schema descriptions cover them adequately.

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 in a 1:1 conversation with a participant, specifying the verb (read), resource (DM events), and scope (1:1 conversation). It also distinguishes from siblings like list_dm_inbox and list_dm_conversation_events by focusing on the 1:1 participant context.

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 usage for reading DM events with a participant, and provides the prerequisite of dm.read scope. However, it does not explicitly mention when to prefer this over alternatives like list_dm_conversation_events, nor does it state when not to use 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 no annotations provided, the description carries the transparency burden. It explicitly states this is a read operation and discloses the required OAuth scope. It could add detail about ordering or pagination, but for a simple read-only list tool the disclosure is adequate.

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 deliver purpose, scope, and auth requirement without waste. Every phrase adds value and the description is front-loaded with the action verb.

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 low-complexity tool with one optional parameter and no output schema, the description is largely complete. It explains what the tool does, the scope, and the required permission. The only minor gap is not explicitly differentiating from the similarly named list_dm_events sibling.

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

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

The input schema fully describes the single optional maxResults parameter including default and maximum, so schema coverage is 100%. The description adds no extra parameter semantics, matching the baseline for high schema coverage.

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

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

The description clearly states the tool reads recent DM events across all conversations (inbox view), using a specific verb and resource. It distinguishes itself from sibling tools like list_dm_conversation_events by emphasizing the all-conversation inbox scope.

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 (inbox view, all conversations) and a required prerequisite (dm.read scope). It does not explicitly name alternatives or exclusions, but the phrasing implicitly separates this from per-conversation event listing.

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

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

With no annotations, the description must carry the burden of behavioral disclosure. It does indicate a read-only listing operation and adds the context of 'locally stored', but it does not disclose return format, auth requirements, or rate limits. It does not contradict anything, but there are gaps.

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

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

The description is a single, efficient sentence with no redundancy. Every word contributes meaning, making it appropriately concise and well-structured.

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

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

The tool has a single optional parameter and no output schema. The description sufficiently explains what the tool does and the filtering option, but it does not mention the return format or any side effects, which might be expected given the lack of an output schema. For a simple list tool, this is acceptable but not fully complete.

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

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

The input schema's status parameter has a description that fully explains its purpose, and the overall schema coverage is 100%. The description merely repeats this with 'optionally filtered by status', adding no new 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?

The description uses the verb 'List' and specifies the resource 'locally stored drafts', which clearly indicates the operation's scope. It is distinct from sibling list tools like list_dm_drafts and list_retweet_drafts, though not explicitly named. The addition of 'locally stored' adds context, but it does not explicitly contrast with alternatives, so it falls short of a 5.

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

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

The description implies the tool is for retrieving drafts and optionally filtering by status, but it gives no explicit guidance on when to prefer this tool over other list tools or any exclusions. There is no mention of alternative tools or conditions for use, so it only provides implied 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?

With no annotations provided, the description carries the full burden of explaining behavior. It states the operation is a listing, which implies read-only, but does not disclose whether the list includes deleted drafts, the return format, or any scoping limitations. The phrase 'retweet/undo drafts' adds some context but lacks 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 a single short sentence that is front-loaded with the action and resource. It contains no unnecessary words and 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?

Given the tool's simplicity (one optional param, no output schema) and the absence of annotations, the description covers the core action and filter capability. However, it does not explain what the returned list contains (fields, ordering, inclusion of deleted drafts), leaving some gaps for an agent to infer.

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

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

The input schema fully describes the only parameter (status) with an enum and explicit description. The description merely echoes the schema by saying 'optionally filtered by status,' adding no new semantic meaning beyond what the schema already provides.

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

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

The description clearly identifies the action ('List') and the resource ('retweet/undo drafts'), distinguishing it from the general list_drafts tool. The optional status filter is also mentioned, making the tool's purpose unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives such as list_drafts or list_dm_drafts. It does not mention exclusions or scenarios where another tool would be more appropriate.

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

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

With no annotations, the description carries the full burden. It discloses the return values (user id and DM eligibility) but does not explicitly state read-only behavior, authentication needs, or rate limits. For a lookup tool, the read-only nature is implicit but not explicit.

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

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

Two sentences, front-loaded with the purpose, and zero wasted words. Every phrase adds value: the core resolution, the DM eligibility detail, and the usage 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?

The description explains what the tool returns (user id and DM eligibility), which is critical given the absence of an output schema. It lacks details on response structure or error cases, but for a simple one-parameter lookup, this is nearly complete.

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

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

The schema already describes the username parameter with 100% coverage (including the leading @ handling). The description adds minimal semantic value beyond the schema, only reinforcing the handle terminology, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool resolves an X @handle to a user id, and adds the specific capability of determining DM eligibility. This distinct action and resource set it apart from sibling tools like get_x_account or create_dm_draft.

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 says 'Useful before create_dm_draft,' providing a clear when-to-use context. It also implies this is the tool for handle resolution, distinguishing it from account-level lookups.

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

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

With no annotations provided, the description carries the full burden. It discloses the API used (X API v2), supported content types, failure behavior for unapproved drafts, a configuration dependency (unless approval is disabled), and the return value (live post URL(s)). This is solidly transparent, though it omits potential side effects like draft state changes after publishing.

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 exactly two sentences: the first gives the core purpose, the second packs in capabilities, failure conditions, and return value. Every sentence earns its place with no redundancy 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 simple one-parameter tool with no output schema, the description adequately covers inputs, behavior, and outputs. It mentions supported feature types and edge-case failure, making it mostly complete. It could have mentioned what happens to the draft after publishing, but this is a minor omission.

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

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

The single 'id' parameter is fully described in the schema as 'Draft id', and the tool description does not add any extra semantics beyond that. Since schema coverage is 100%, a baseline of 3 is appropriate.

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

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

The description clearly states the tool 'publish[es] an approved draft to X via the X API v2', with a specific verb (publish) and resource (draft). It distinguishes from sibling tools like list_drafts or approve_draft by focusing on the action of publishing, and even lists supported content types, reinforcing its unique role.

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 implicitly defines the usage context by noting the draft must be approved, and explicitly states it 'fails if the draft has not been approved yet', making the prerequisite evident. While it doesn't name alternative tools, the approval requirement signals that approve_draft should be used first, and the lack of mention of alternatives is a minor gap.

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

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

With no annotations provided, the description carries the transparency burden. It states the state change ('Mark rejected') and adds a non-obvious behavior (reconciling a stuck draft), which is valuable. However, it does not disclose side effects, reversibility, permissions, or what happens to the draft after rejection, leaving gaps for a mutation tool.

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

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

The description is two sentences long, front-loaded with the primary action, and the second sentence adds a meaningful use case without unnecessary detail. Every word earns its place, making it concise and well-structured.

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

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

For a simple tool with one parameter and no output schema, the description covers the core purpose and a useful edge case (reconciling a stuck send). It omits deeper behavioral details, but given the tool's simplicity and the lack of annotations, it is reasonably complete for an agent to select and invoke it correctly.

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

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

The input schema fully covers the only parameter 'id' with a description ('DM draft id.'), achieving 100% schema description coverage. The tool description adds no additional parameter semantics, so the baseline score of 3 applies.

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

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

The description clearly states 'Mark a DM draft rejected' with a specific verb and resource, and the scope is narrowed to DM drafts, distinguishing it from the sibling 'reject_draft' for regular drafts. It also adds a secondary purpose (reconciling a stuck sending state), further clarifying intent.

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 primary usage is evident from the description, and the second sentence provides a concrete additional scenario ('draft stuck in sending after a failed attempt'), which guides when to use the tool. It does not explicitly mention alternatives or exclusions, but the DM-specific naming and the additional use case give adequate context among 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?

No annotations are provided, so the description carries the full burden. It discloses the key behavioral consequence (rejected drafts cannot be published) and specifies the reconciliation use case. However, it does not mention whether rejection is reversible, what the response looks like, or any permission requirements, leaving some gaps.

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

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

Three sentences, each earning its place: the first states the core action, the second introduces the reconciliation use case, and the third provides an alternative. No fluff or 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 one-parameter tool with no output schema and no annotations, the description covers the main purpose, an edge case, and a sibling alternative. It lacks details on return values or error handling, but the absence is not critical for selection/invocation. Slightly more would make it fully complete.

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

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

Schema description coverage is 100% with a single parameter 'id' described as 'Draft id.' The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource ('Mark a draft as rejected') and clearly states the consequence ('Rejected drafts cannot be published'). It distinguishes the tool from siblings like approve_draft and publish_draft, and even differentiates from delete_published_draft.

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 explicit usage context for a special scenario: reconciling a draft stuck in 'publishing' after a crashed publish_draft call, with a clear condition ('once you have verified the post did NOT go out on X'). Also names an alternative tool (delete_published_draft) when live post ids were recorded, giving clear when-to-use vs when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the full burden. It states the action (mark rejected) but does not disclose potential side effects, reversibility, or permission requirements. The reconciliation use case adds some behavioral context, but overall transparency 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 two sentences, direct and waste-free. The key action is front-loaded, with the additional reconciliation use case provided as a bonus, all without 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?

Given the low complexity (one parameter, no output schema), the description covers the primary purpose and a secondary scenario. However, it could be more explicit about the meaning of 'retweet/undo draft' and what the rejection state implies for draft management, which leaves a small gap.

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

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

The input schema fully describes the 'id' parameter as 'Retweet draft id.' With 100% schema coverage, the description adds no additional parameter information, warranting the baseline score of 3.

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's function: marking a retweet/undo draft as rejected. The verb 'Mark' and resource 'retweet/undo draft' are specific and distinguish it from sibling tools like reject_draft (for regular drafts) and approve_retweet_draft (the approval counterpart).

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 a primary use case and an explicit secondary scenario: 'Also usable to reconcile a draft stuck in executing after a failed attempt.' This gives clear context for when to use it. However, it does not explicitly mention alternatives or when not to use it, though the tool name implies it is specific to retweet drafts.

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

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

With no annotations, the description carries the full burden. It adds useful context by stating the required 'tweet.write' scope and the immediacy ('immediately'), but it does not disclose side effects such as whether the draft is consumed or can be undone (though undo_retweet exists as a sibling).

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

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

The description is a single, dense sentence that covers the action, resource, endpoint, and scope requirement without unnecessary words. It is well-front-loaded and easy to scan.

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

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

For a one-parameter tool with no output schema, the description covers the core aspects: what it does, the endpoint, the scope, and the draft precondition. It could mention the return value or relationship to undo_retweet, but overall it is complete enough for basic usage.

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

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

The schema description for 'id' is simple ('Retweet draft id (action must be retweet)'), while the tool description adds the important constraint that the draft must be 'approved.' This clarifies when the tool can be used and goes beyond the schema.

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

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

The description clearly states the action ('Retweet an approved draft'), the target ('to X'), and the mechanism ('via POST /2/users/:id/retweets'). It distinguishes from sibling draft-management tools by focusing on the posting action, not drafting or approving.

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 tool is used when you have an approved retweet draft and want to post it immediately. It does not explicitly mention alternatives or when not to use it, but the condition 'approved draft' and endpoint give some context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly mentions rate limits (hourly, daily, min interval) and required scopes (dm.read, dm.write), along with a re-auth note, which are valuable behavioral traits beyond what the schema indicates.

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 concise, consisting of three short sentences. It is front-loaded with the primary action, followed by important constraints and requirements, with no superfluous information.

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

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

For a simple tool with one parameter and no output schema, the description covers the core action, approval prerequisite, rate limits, and auth scopes. It could include return value notes, but the provided context is sufficient for a sending action.

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

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

The input schema has 100% coverage for the single 'id' parameter with description 'DM draft id.' The tool description does not add any parameter-specific details, but the schema already sufficiently documents the parameter, so it meets the baseline.

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

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

The description clearly states the action ('Send an approved DM draft') with a specific verb and resource. The inclusion of 'approved' and 'DM draft' distinguishes it from sibling tools like approve_dm_draft or create_dm_draft.

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 the draft must be approved and requires specific scopes, giving clear context for when to use it. It does not explicitly mention alternatives or exclusions, but it is clear that this is for sending an already-approved DM draft.

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

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

With no annotations provided, the description carries the burden. It discloses the HTTP method (DELETE), endpoint, 'immediate' execution, and 'tweet.write' scope. However, it does not explain the effect on the original draft or whether the action is reversible, leaving some behavioral ambiguity.

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 includes the action, resource, endpoint, and required scope. It is front-loaded and contains no unnecessary words, earning 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 tool with no output schema, the description covers what it does, how via the endpoint, and the authentication requirement. It is complete enough for an agent to invoke the tool, though it could mention the response format or edge cases.

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

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

The input schema has 100% coverage with the description 'Retweet draft id (action must be undo).' The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('undo') and resource ('approved retweet draft'), and includes the exact endpoint (DELETE /2/users/:id/retweets/:tweet_id). This clearly distinguishes it from sibling tools like approve_retweet_draft and reject_retweet_draft.

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

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

It states the tool is for undoing an approved retweet draft, providing clear context for when to use it. It does not explicitly name alternatives or exclusions, but the phrase 'approved retweet draft' implies it is not for other draft states.

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

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

With no annotations, the description carries the full burden of disclosing side effects. It transparently notes that null clears optional fields and that approved drafts are reset to draft status—behavior not obvious from the schema. However, it omits other potential details like permissions or return values, so it is not maximally transparent.

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

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

The description is exceptionally concise—two short sentences—with the primary purpose front-loaded in the first sentence. Every word adds value, and it avoids repeating schema details. This is a model of efficient phrasing.

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

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

Given the tool has 9 parameters, no annotations, and no output schema, the description provides key behavioral context (null clearing, status reset) but does not cover return values, required prerequisites, or potential side effects beyond the reset. The schema fills in parameter details, but for a mutation tool of this complexity, more contextual guidance would be beneficial.

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

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

Schema description coverage is 100%, and each nullable parameter already states 'or null to clear.' The description's statement 'Pass null to clear optional fields' merely restates what the schema already conveys, adding no new meaning. Thus a baseline score of 3 is appropriate.

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

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

The description begins with 'Edit a DM draft,' which clearly states the tool's action (edit) and resource (DM draft). This distinguishes it from the sibling tool 'update_draft,' which likely targets a different draft type. The title reinforces the DM-specific scope.

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 usage via the name and the phrase 'DM draft,' but it does not explicitly state when to use this tool over alternatives like 'update_draft' or other draft operations. No exclusions or alternative tool references are provided, leaving usage guidance 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?

With no annotations, the description carries the full transparency burden. It discloses critical behaviors: the http(s) link restriction, reset of approved drafts to "draft" status, null-to-clear semantics, and the text/parts precedence rule. It does not mention permissions or response shape, but the disclosed side effects are substantive and give the agent a reliable mental model.

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 but information-dense. It leads with the action, then packs essential rules into a few sentences. Each sentence adds a distinct piece of guidance. Slightly longer than the minimal, but every clause earns its place.

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

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

For a 10-parameter mutation tool with no annotations and no output schema, the description covers purpose, key behavioral rules, null handling, state transitions, and the sibling alternative. It omits minor details like mutual exclusivity constraints and response format, but the former is in the schema and the latter is less critical given the absence of an output schema.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema: the "Same link rule as create_draft" clarifies URL handling, "Pass null to clear an optional field" generalizes null semantics, and "text wins and becomes parts[0]" explains a precedence not fully evident from the schema. This elevates the parameter understanding.

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 clear verb and resource: "Edit a draft's content" followed by a specific list of editable fields. It explicitly distinguishes itself from the sibling tool update_published_draft by stating "To change a live post, use edit_published_draft," making scope unambiguous.

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

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

Provides explicit guidance: references the same link rule as create_draft, warns about the approved-draft reset behavior, and names the alternative tool for live posts. This directly answers when to use this tool vs. alternatives.

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