x-use

by ihuzaifashoukat

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.1
Disambiguation5/5
Each tool has a distinct, clearly defined purpose covering account management, posting, queuing, drafting, searching, proxy management, and health checks. There is minimal overlap; for example, queue_post vs post_tweet are differentiated by queuing vs direct posting, and generate_and_post is a convenience wrapper. The descriptions further clarify boundaries.
Naming Consistency5/5
All tools use a consistent verb_noun pattern in snake_case (e.g., list_accounts, get_metrics, add_proxy, approve_draft). No camelCase or mixed conventions. The verbs are predictable (list, get, add, update, remove, set, queue, cancel, etc.), aiding agent understanding.
Tool Count4/5
33 tools is on the higher end but justifiable given the breadth of the X automation domain. The tools cover account lifecycle, posting, engagement, queues, drafts, proxy management, metrics, and batch runs. While comprehensive, the count could be slightly reduced by merging some like generate_and_post with post_tweet, but overall it is well-scoped.
Completeness4/5
The tool surface covers CRUD for accounts, posting, queuing, drafting, search, engagement, proxy management, and health. Notable omissions include direct messaging, analytics, and follower management, but these may be out of scope. Core workflows for automation are well-covered.
Average 4.2/5 across 33 of 33 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 86 commits in the last 12 weeks
- Last stable release on July 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description repeats the annotation's readOnlyHint as 'Read-only', which is redundant. No additional behavioral traits (e.g., error conditions, rate limiting, or side effects) are disclosed. The annotation already covers safety, so the description adds no extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences. No unnecessary words, and it front-loads the core purpose. Perfectly sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 required param, read-only, with output schema), the description adequately covers the basics. It could mention that the draft_id must exist, but the output schema likely provides return field details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for its single parameter (draft_id), and the tool description does not provide any additional meaning, constraints, format, or examples. The description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Show', the resource 'draft', and the identification method 'by id'. This effectively distinguishes it from sibling tools like list_drafts (list all) and approve_draft (modify).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific draft id, but it does not explicitly state when to choose this tool over alternatives like list_drafts, approve_draft, or reject_draft, nor does it mention any prerequisites or prohibitions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint false, destructiveHint false, idempotentHint true. The description adds behavioral context by specifying state transition constraints, which goes beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, no fluff, front-loaded with the main purpose followed by constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's purpose and constraints. It does not explain response or prerequisites, but given the output schema exists and the tool is simple, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate but does not mention the queue_id parameter. The parameter name is self-explanatory, but no additional semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Cancel' and the resource 'queued action', and specifies the allowed states (pending or failed). It does not explicitly differentiate from siblings like reject_draft, but the state constraints provide implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides conditions for use (only pending or failed items) and what cannot be cancelled, but it lacks explicit guidance on when to use this tool versus alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds beyond annotations by stating 'never starts a browser' and clarifying that payloads are shown exactly as they will fire, providing useful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no unnecessary words. It front-loads the core function and adds a key behavioral note immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core purpose and behavior. However, it omits explanation of the two parameters as filters, and does not mention ordering or pagination. An output schema exists which partially compensates, but parameter semantics are lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so both parameters (status, account) have no descriptions. The tool description does not explain these parameters or their expected values/formats, leaving the agent to infer from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'queued actions', specifying that it shows full payloads and per-status counts. It distinguishes from sibling tools like 'queue_post' which enqueues actions, and 'process_queue' which processes them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use versus alternatives. The description does not mention scenarios where this tool is appropriate or when not to use it, nor does it reference sibling tools with different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false) and idempotency (idempotentHint=true). The description adds value by disclosing that pausing closes the warm browser session, which is not inferable from annotations or schema. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the core purpose ('Enable or pause an account') and adds a critical behavior detail in the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and is relatively simple, the description covers the main purpose and one behavioral nuance. However, it lacks parameter semantics and usage guidance, making it incomplete for an agent to use confidently without further inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate. It implies the 'active' boolean controls enable/pause, but does not explicitly map true/false to states. The 'account' parameter is entirely unexplained, leaving the agent to guess the format or context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enables or pauses an account, and distinguishes itself from deletion by saying 'without deleting it'. It also specifies a key behavioral detail about pausing closing the browser session. This provides a specific verb+resource and distinguishes from siblings like remove_account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any explicit guidance on when to use this tool versus alternatives such as update_account, nor does it explain scenarios for enabling vs pausing. It only contrasts with deletion, leaving ambiguity about its role among sibling account management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation (readOnlyHint=false) and non-destructiveness. The description adds that every candidate passes a relevance gate, max_actions is capped per account, and draft mode prevents execution. These details go beyond annotations, though the direct execution mode is only implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, about 60 words, front-loaded with purpose. Every sentence adds essential information without fluff. Well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown) and siblings, the description covers core behavior: actions, draft mode, caps. It does not explain return values or error handling, but these are inferred from the schema. Overall adequate for standard usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description clarifies that actions is a subset of ['like', 'retweet'] with default ['like'] and that max_actions is hard-capped. However, keywords and account are not explained, and the schema lacks enums. The description adds moderate value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool engages with tweets from keyword search using actions like or retweet. It specifies the verb 'engage' and the resource 'tweets found via keyword search', but does not explicitly differentiate from siblings like queue_engagement or reply_to_tweet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions draft mode by default and hard-capped max_actions, implying when to use (mass engagement with approval). However, it does not explicitly state when not to use or provide alternatives, leaving some reliance on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations by explaining the draft mechanism: the generated text is stored in a draft's payload/preview for human review before posting. However, it does not disclose whether a non-draft mode exists or other side effects like rate limits or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence clearly states the core functionality, and the second adds the critical draft mode detail. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (reducing the need to explain return values), the description omits important lifecycle context: it does not mention that the tool creates a draft that requires manual approval via sibling tools like 'approve_draft'. The name 'generate_and_post' is misleading as the default behavior is to only draft.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the 'topic' parameter by name and context, but does not explain the 'account' parameter. With 0% schema description coverage, the description adds partial value but falls short of fully compensating for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a post on a given topic using an LLM and then posts it, with a default draft mode. This distinguishes it from sibling tools like 'post_tweet' (post without generation) and 'draft_post_variations' (generate drafts without posting).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the default draft mode but does not explicitly state when to use this tool vs. alternatives such as 'post_tweet' or 'draft_post_variations'. There is no guidance on when not to use it or what the non-draft mode (if any) entails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. Description adds valuable context 'never starts a browser', which is beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and a single simple parameter, the description covers the main points: what data is returned and that it's read-only. Could be enhanced by specifying account identifier format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter 'account' with 0% description coverage. Description mentions 'for an account' but does not specify expected format or how to identify the account. Fails to compensate for lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Read', the resource 'recorded metrics for an account', and specifics 'counters + recent events'. Distinguishes from siblings like get_account_health by focusing on metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies safe usage with 'Read-only, never starts a browser', but does not explicitly state when to use vs alternatives like get_account_health or list_accounts. Lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. Description adds details on include_images effect, return content, and explicitly states no posting occurs, adding value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one short paragraph with front-loaded purpose, followed by important nuance on include_images, and ends with a safety note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main return items and behavior, output schema exists so full return details are documented elsewhere. Lacks error handling details, but acceptable for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. Only include_images is explained; account and tweet_url lack any description, leaving their semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it fetches one tweet and lists returned data: text, author, counts, media, persona. Distinguishes from write tools by noting 'Read-only' and 'Nothing is posted'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for fetching a single tweet, but no explicit when-to-use or alternatives. Does not distinguish from similar read tools like get_metrics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses execution path and idempotency (once-only), but the annotations' destructiveHint=false may conflict if execution is destructive; description does not clarify.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the action and add key constraints without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and usage well; output schema exists for return values. Lacks detail on what 'execute' entails but sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter with no schema description, but description adds meaning by stating behavior for unknown/consumed ids, raising baseline from 1 to 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a pending draft created by a write tool, distinguishing it from siblings like reject_draft and list_drafts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for when to use (after a write tool creates a draft) and includes constraints (approve once, error on invalid ids). Could explicitly contrast with reject_draft.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false), description clarifies that the tool creates drafts but does not post, and mentions persona-aware server-side LLM. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first explains the main action, second clarifies behavioral constraints and requirements. No unnecessary words, and critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, but description does not explain the return value. Additionally, it lacks explanation for the 'account' parameter. Given moderate complexity, more context on parameter usage would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain all parameters. It mentions 'count' and 'topic' but does not explain 'account', which is a required parameter. This leaves ambiguity about which account is used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action: generate distinct takes on a topic using server-side LLM and stage as drafts. It specifies the verb (generate), resource (post drafts), and scope (count distinct takes). This distinguishes it from siblings like 'prepare_reply' and 'generate_and_post'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains that nothing is posted and one can approve or reject drafts, and it lists the prerequisite (LLM block in settings). However, it doesn't explicitly state when not to use or compare to alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint=false) and open-world effects (openWorldHint=true). The description adds the draft mode behavior and the need for approval, which is useful context. However, it does not elaborate on other side effects or requirements, leaving open-world behavior somewhat vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no wasted words. The first sentence covers purpose and parameter clarification; the second explains the critical draft mode behavior. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown) and annotations cover safety, the description provides all essential context: purpose, parameter clarification, draft mode behavior, and cross-reference to approve_draft. No gaps for an agent to correctly select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly defines 'media' as local file paths and 'community' as target community id. The other parameters (text, account) are self-explanatory from the schema. This provides sufficient meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose ('Post a tweet from an account') and explains specific parameters (media, community). It distinguishes from siblings by mentioning draft mode, but does not explicitly differentiate from similar posting tools like generate_and_post or reply_to_tweet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on draft mode: 'In draft mode (default) returns a draft for review and posts nothing; approve_draft(draft_id) executes it.' This tells the user when to use draft vs direct posting, but does not contrast with alternative posting tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains draft mode and the read-only fetch for auto-generation, providing important behavioral context beyond the annotations (which indicate non-read-only but not destructive). However, it does not clarify how to exit draft mode or the exact output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loading the purpose, then adding key details about parameters and behavior. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, output schema exists), the description covers purpose, text options, and draft mode adequately. Missing details like account format are minor since output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'text' parameter (explicit value or 'auto'), which is helpful given 0% schema coverage. However, it does not explain 'account' or 'tweet_url' formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Reply to a tweet' as the core action, and distinguishes from sibling tools like 'post_tweet' by emphasizing draft mode and the auto-generation feature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for replying with optional auto-generation, but does not explicitly state when to use this tool versus alternatives (e.g., 'post_tweet' for new posts) or 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant value beyond annotations: it explains that only provided fields change (idempotent behavior), how to clear specific fields, and that the warm browser session is closed (side effect). This aligns with annotations (idempotentHint true, destructiveHint false) and provides concrete 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 4 sentences, front-loading the purpose. Each sentence adds value, though it could be more structured (e.g., grouping parameter behaviors).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters and 1 required, the description covers key behaviors but fails to document several parameters. The output schema likely exists, but the description should at least mention the scope of partial updates. Adequate for a complex tool but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description partially compensates by explaining proxy, persona, and cookie_file semantics. However, it does not describe other parameters (is_active, self_handles, action_config, target_keywords, competitor_profiles), leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Partially update an account' and lists the updatable fields (proxy, persona, cookie_file, etc.). It clearly distinguishes from sibling tools like add_account, remove_account, and set_account_active by focusing on partial updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating account settings but does not explicitly state when to use this tool versus alternatives like add_account or set_account_active. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true. The description adds value by clarifying the tool never starts a browser and that config failures are reported (not raised), which is useful behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each concise and front-loaded with essential information. No superfluous words; every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema existence and simplicity of parameters, the description covers the tool's purpose and key behaviors. However, missing parameter semantics is a notable gap for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only one parameter ('account') and 0% schema description coverage, the description fails to explain what format or identifier the account expects (e.g., username, email, ID), leaving ambiguity for an AI agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a 'Read-only health snapshot for one account' and enumerates specific checks (config presence, cookie-file validity, metrics counters, etc.), distinguishing it from sibling tools like get_metrics or list_accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context (read-only, never starts browser) and explains error handling, but does not explicitly state when to use this tool versus alternatives or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-destructive and idempotent behavior. The description adds that it is a 'local status change only, nothing touches X,' clarifying it does not affect external systems. This is consistent with annotations and provides additional insight into the tool's 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no wasted words. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and an output schema, so the description is adequate. It explains the core action and side effects (local, no external impact). However, it could briefly mention that the draft's state changes to rejected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'draft_id', is required but the description provides no additional meaning beyond the schema. With 0% schema description coverage, the description should compensate but does not explain what the parameter represents or how to use it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Reject a pending draft so it can never be approved.' It uses a specific verb ('reject') and resource ('draft'), and distinguishes itself from sibling tools like 'approve_draft'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for usage: 'Local status change only, nothing touches X.' This implies it is safe and non-destructive. However, it does not explicitly state when not to use it or compare it to alternatives like deleting or canceling drafts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations: it explains the 'keyless heuristic', 'persona-aware' LLM usage, that replies are staged as drafts, and the requirement for the 'llm' block. Annotations already indicate mutability (readOnlyHint=false), and the description aligns without contradiction. It does not address rate limits or auth, but overall provides good 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences), front-loaded with core actions, and avoids redundancy. Every sentence contributes essential information: search, filter, generate, stage, review instructions, and requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the multi-step workflow, staging behavior, and required configuration. With an output schema present, return values are handled. It could be more explicit about the number of drafts (linked to max_items) and the 'keyless heuristic', but overall provides sufficient context for an agent to understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains 'keywords' and implies 'account' via 'Search each keyword' and 'write a reply per tweet', but 'max_items' is unmentioned. No details on the filtering heuristic or account selection logic. The description adds partial meaning but leaves key parameter semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches keywords, filters tweets, writes replies using LLM, and stages drafts. It distinguishes from siblings like 'reply_to_tweet' (which posts) by emphasizing 'Nothing is posted' and directing to 'list_drafts' for review. The action flow is specific and well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool for bulk research and drafting without posting. It implicitly differentiates from siblings by noting the draft staging and review workflow. However, it lacks explicit 'when not to use' or direct comparisons to similar tools like 'prepare_reply', leaving some ambiguity for agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint annotation: it reveals that omitting run_id returns all runs since boot, and it uses the verb 'poll' indicating non-blocking repeated calls. It also explicitly states 'Read-only' which aligns with the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three short statements with no wasted words. It front-loads the verb and resource, then specifies parameter behavior and read-only nature. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and one optional parameter, the description covers the key behavioral aspects: polling mechanism, parameter dependency for listing all vs. specific run, and read-only nature. It does not explain what a 'run_cycle handle' is, but the tool name and context likely make it clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the run_id parameter. The description compensates by explaining the effect of omitting run_id (lists all runs since boot) and implies that providing it polls a specific handle. This adds crucial meaning beyond the schema's type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'poll' and the resource 'run_cycle handles'. It specifies two behaviors: polling a specific run (when run_id given) and listing all runs since boot (when omitted). This distinguishes it from sibling tools like run_cycle (which likely initiates runs) and list_accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to check status of run cycles, but it does not explicitly state when to use it versus alternatives like run_cycle or process_queue. It provides context about omitting run_id but no exclusions or scenarios where another tool would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations by detailing secret stripping and that no browser is started, which are important behavioral traits not covered by readOnlyHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and existence of output schema, the description fully covers necessary context for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline of 4 applies; no additional parameter information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists configured accounts with secrets stripped, distinguishing it from sibling get_account which returns details for a single account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for viewing all accounts without secrets, but does not explicitly state when to use this tool versus alternatives like get_account or list_proxies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint annotation by disclosing critical behavioral traits: the throwaway browser is cookieless and does not use account cookies or warm sessions, it performs an anonymous x.com/home load (contributing to latency), and credentials are masked in the response. It also reveals the side effect of advancing a round-robin pool's rotation cursor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of several sentences, front-loaded with the core purpose. Each sentence adds value, but there is slight redundancy (e.g., 'throwaway browser' mentioned twice). Overall, it is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (side effects, optional parameters, output schema exists), the description covers the main behavior, parameter interactions, and response content (egress IP + latency). Minor gaps exist, such as what happens if neither proxy_url nor account is provided, but the description implies at least one should be set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning by explaining the interaction between proxy_url and account parameters (precedence and how account resolves to a URL or pool assignment). However, it does not specify expected formats (e.g., 'socks5://...' or 'pool:...') or provide examples, which may leave ambiguity for invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Probe a proxy with a throwaway browser' and details the actions: resolving proxy, opening an IP-echo page, reporting egress IP and latency. This specific verb+resource combination distinguishes it from siblings like list_proxies or add_proxy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on parameter precedence ('explicit proxy_url wins; otherwise the account's direct URL or pool:<name> assignment') and a specific usage nuance ('With a round_robin pool, probing via `account` advances the pool's rotation cursor'). However, it does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: atomicity, backup/validation, and the privacy property of cookie_file. Annotations are minimal, so the description carries the burden well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core action and then elaborates key parameters, achieving high information density per word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown) and 6 parameters (1 required), the description covers the most important behavioral aspects (atomicity, cookie handling) but does not explicitly mention which parameter is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates partially by detailing cookie_file and persona. However, it omits explanations for proxy, is_active, target_keywords, leaving gaps for half the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and the resource 'account to config/accounts.json', specifying it is validated, backed up, and atomic. It distinguishes this from sibling tools like update_account and remove_account by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for the cookie_file and persona parameters, including constraints (path on this machine, max 4000 chars) and behavior (cookie values never pass through). However, it does not explicitly state when to use this tool over alternatives like update_account.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: 'Validated, deduped, backed up, atomic. Credentials are masked in the response.' This complements the idempotentHint and destructiveHint annotations effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: main action first, then key behavioral traits, then usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers creation, validation, idempotency, credential masking, and post-usage. Lacks error handling or edge cases (e.g., duplicate pool name), but output schema likely fills gaps. Good for a focused creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% so description must compensate. It identifies the two parameters ('proxy URL' and 'pool') but lacks detailed format or constraints. Validation is mentioned but not specified. Adequate but not thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Add a proxy URL to a named pool' and specifies the target resource ('settings.json'). It clearly distinguishes from sibling tools like 'remove_proxy' and 'test_proxy' by focusing on addition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on how to assign the added proxy to accounts via 'update_account(proxy="pool:<name>")'. Implicitly contrasts with removal/testing tools, but lacks explicit when-not-to-use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations: specifies that cookies, password, and proxy credentials are masked, and that no browser is started. Aligns with readOnlyHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, effectively communicates core behavior and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with an output schema and clear annotations, the description adequately covers behavioral traits, output content, and safety. No missing information for its scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'account' parameter lacks schema description and the tool description does not specify its format or expected values. With 0% schema description coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it shows one account's masked config and cookie-file status. Distinguishes from siblings like list_accounts and get_account_health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates it is read-only and never starts a browser, conveying safe usage context. However, it does not explicitly contrast with sibling tools or provide when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description reinforces with 'Read-only'. It adds ordering ('newest first') and filter details, but does not mention potential pagination or response shape beyond the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The main action is front-loaded, and parameter details are compactly listed. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with 3 optional parameters and an output schema, the description covers purpose, ordering, parameter meanings, and safety. It is complete given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well: it lists possible status values, explains that account filters by ID, and states the max limit of 100. This adds significant meaning beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List drafts' with a specific verb and resource, and adds ordering 'newest first'. It differentiates from sibling tools like 'get_draft' (for a single draft) and other CRUD tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for listing drafts but lacks explicit guidance on when to use this vs alternatives like 'get_draft' or 'list_queue'. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (non-readOnly, non-destructive), and the description compensates by disclosing queuing behavior, the 'auto' feature for reply text that scrapes the tweet now, and the requirement to call process_queue for execution. This is sufficient for understanding the tool's safety and behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each adding value. The first states the core purpose, the second explains the action parameter and reply requirement, and the third clarifies execution dependency. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4-parameter input schema and output schema presence, the description covers the essential behavioral aspects: queuing, deferred execution, and the special reply behavior. It could hint at list_queue or cancel_queued_action for completeness, but the current content is adequate for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant meaning: it explains that 'action' must be like/retweet/reply (though no enum in schema), that reply requires 'text', and that 'auto' generates a reply immediately. It clarifies the interplay between action and text, though account and tweet_url are not elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queues a like, retweet, or reply, specifying the action parameter and that reply requires text. It distinguishes itself from process_queue which executes the queue, and from siblings like engage and reply_to_tweet by emphasizing paced execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the tool is for queuing actions and that nothing executes until process_queue is called, providing clear guidance on deferred execution. However, it does not explicitly compare with immediate-action siblings like engage or reply_to_tweet, leaving some ambiguity about when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the payload is finalized at queue time (LLM generation is NOW) and that execution requires process_queue, adding value beyond the annotations which only indicate non-read-only and non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the primary action front-loaded and all key details included without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity and presence of an output schema, the description covers essential behavior but misses details on media and community parameters. Overall, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the text/topic relationship and not_before as ISO 8601, but does not cover media, account (required), or community parameters. With 0% schema coverage, more parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Schedule a post for paced execution' and explains the two modes (verbatim text or LLM-generated topic), distinguishing it from immediate posting tools like post_tweet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use this tool (to schedule a post) and mentions that nothing executes until process_queue is called, but does not explicitly state when not to use it (e.g., for immediate posting).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true), the description reveals critical side effects: closes the warm session, writes a backup, and leaves the cookie file on disk. This adds significant 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly written sentences with no redundancies. Each sentence serves a distinct purpose: action, prerequisite, and side effects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behavioral aspects and side effects. It does not mention output or error cases, but an output schema exists (not shown). The idempotency hint from annotations is not addressed, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds important meaning for the 'confirm' parameter (must be true), but does not describe the 'account' parameter beyond its name. Partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove an account') and the specific resource ('from config/accounts.json'), distinguishing it from siblings like add_account, update_account, and set_account_active.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the requirement ('Requires confirm=true'), guiding the agent on how to successfully invoke the tool. However, it does not provide explicit comparisons to alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive behavior, and the description adds crucial details: confirmation requirement, allowed emptying with fallback, and response listing accounts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each providing essential information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema, the description sufficiently covers usage conditions, side effects, and response content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description should compensate for parameters. It only explains the 'confirm' parameter's requirement, but provides no meaning for 'pool' or 'proxy_url' beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Remove a proxy URL from a pool', which is a specific verb-resource combination. It effectively distinguishes from siblings like add_proxy and test_proxy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly requires confirm=true, and explains the outcome when emptying a pool. Alternatives are not mentioned, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond annotations: it runs in the background, never silent-blocks, returns a handle immediately, logs progress, and ensures config files are untouched. These details add significant context that annotations (readOnlyHint=false, destructiveHint=false) do not fully capture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative and front-loaded with the main action, but it could be slightly more concise. The parameter details are integrated into a single paragraph; bullet points might improve readability, but the information density is high and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and an output schema, the description covers inputs well but does not mention the output format beyond 'run handle'. Prerequisites (e.g., account must exist) are not stated. However, the output schema exists to fill the return value gap. Overall, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully explains both parameters: account limits to one account, and pipelines is a comma-separated subset of specific pipeline names with mapping to ActionConfig flags. The CLI equivalent reference adds valuable context. This compensates completely for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool runs a legacy batch automation cycle in the background and returns a run handle. It specifies the verb 'run' and the resource 'legacy batch automation cycle', distinguishing it from siblings like process_queue. The parameter details further clarify the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that draft mode does not apply, which provides a negative usage hint, but it does not explicitly state when to use this tool versus alternatives (e.g., process_queue or engage). There is no direct comparison to sibling tools, so the usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds beyond these: mentions session reuse, draft mode not applying, and detailed image attachment behavior (first photo of up to 5 tweets, bounded, media URLs and alt text always present). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Multiple short sentences, each adding value (purpose, read-only, session reuse, parameter defaults). Efficient but could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description adequately covers behavior (session, images, account default, read-only). No critical gaps for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates partially: explains account default and include_images behavior clearly. Keywords is implied by purpose. However, limit is not explained, leaving its semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search recent X posts for a query string' with a specific verb and resource. It distinguishes itself from sibling tools like get_tweet (single tweet) and search_profile (profile search) by focusing on recent post search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context such as read-only, draft mode not applicable, reuse of warm browser session, and default account behavior. However, it does not explicitly contrast with alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only aspect is covered. The description adds 'never starts a browser,' which provides additional safety context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Specific details (size, masked members, rotation cursor) are front-loaded, making the purpose immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, presence of output schema, and annotations covering read-only, the description fully covers the tool's behavior and return value, including the key safety note.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description adds no parameter info, but that's unnecessary. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource (proxy pools, strategy, assignments, fallback). It distinguishes from sibling tools like add_proxy, remove_proxy, test_proxy by being a comprehensive read-only listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The read-only nature and comprehensive listing imply usage for viewing proxy configurations, but no explicit guidance on when to use vs alternatives. Sibling tools like add/remove are implicitly for modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds value by explaining what data is returned (tweet text, media as image content, account keywords, persona) and confirming no server-side LLM or posting. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first sentence front-loads the purpose, second sentence specifies next steps. Every word earned its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description sufficiently covers the tool's purpose and usage flow. It explains the context provided and the required follow-up actions, making it complete for a preparatory tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters with 0% description coverage. The description implies the role of include_images for media attachment but does not explicitly map parameters. With no schema descriptions, the description could add more detail for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for preparing reply context: providing tweet text, media, account keywords, and persona. It distinguishes itself from siblings like reply_to_tweet and queue_engagement by emphasizing it is read-only and no server-side LLM or posting occurs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs the agent to use this tool before writing a reply, then pass its output to reply_to_tweet or queue_engagement. It provides clear context on the workflow and no ambiguity about when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint), it explains that draft mode does not apply, nothing is posted, and it reuses the account's browser session. Notes default account behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: starts with main action, then details. A bit long but justified by complexity. Could tighten slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, complete coverage of purpose, usage, and behavioral aspects. Provides enough for agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates significantly: explains profile input varieties, include_images effect, and default account. However, limit parameter is not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads recent posts from one X profile, specifying input types (handle, profile URL, tweet URL). It distinguishes from sibling tool search_tweets for topic discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (watch specific people/competitors, re-read own posts) and when not (use search_tweets). Also warns about pinned posts and reposts, advising to check user_handle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond what annotations provide. It discloses that items execute through the same pacing/dedup/metrics path as write actions, uses jittered pacing and daily caps, and explains multi-account behavior when account is omitted. This is valuable for the agent to understand the tool's side effects and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is 2-3 sentences, front-loaded with the core purpose ('drain queued actions with jittered pacing and daily caps'), and every sentence provides essential information. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers both parameters, explains the tool's role as the approval gate, details pacing and caps behavior, and handles the multi-account case. The presence of an output schema means return values are already documented. Given the tool's complexity and the richness of siblings, this description is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining both parameters: 'account' (if omitted, processes all accounts with due items) and 'max_actions' (default 5, bounds each account). This adds crucial meaning beyond the parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool drains queued actions with jittered pacing and daily caps, and explicitly identifies itself as 'the approval gate for queued work.' This specific verb+resource description, along with mention of execution path and multi-account behavior, effectively distinguishes it from siblings like list_queue (listing) and cancel_queued_action (cancelling).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to drain queued actions) and provides key context: omitting 'account' processes all accounts with due items, each bounded by max_actions and its own daily caps. However, it does not explicitly state when not to use it or provide alternatives, though sibling tools exist for other queue operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![x-use MCP server](https://glama.ai/mcp/servers/ihuzaifashoukat/x-use/badges/card.svg)](https://glama.ai/mcp/servers/ihuzaifashoukat/x-use)

Score Badge

Copy to your README.md:

[![x-use MCP server](https://glama.ai/mcp/servers/ihuzaifashoukat/x-use/badges/score.svg)](https://glama.ai/mcp/servers/ihuzaifashoukat/x-use)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ihuzaifashoukat/x-use'

If you have feedback or need assistance with the MCP directory API, please join our Discord server