x-mcp

by rthomas24

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation2/5
Several tools have overlapping purposes: `account_pulse` and `post_performance` both report on post metrics, `inbox` and `conversation` both list mentions/replies, `scout` and `search` both query posts, and `handoff` bundles multiple sub-actions (list, draft, approve) that overlap with `approvals` and `draft_check`. The descriptions help, but an agent would need to read carefully to pick the right tool.
Naming Consistency2/5
Naming is a mix of nouns (doctor, scout, handoff), verbs (publish, delete_post, schedule), and composites (account_pulse, draft_check, suggest_follows). No consistent pattern like verb_noun throughout. Some names are opaque (doctor, scout) while others are descriptive, making the set feel ad hoc.
Tool Count3/5
23 tools is on the heavy side, but the server covers a wide domain: reading/writing posts, DMs, analytics, contacts, approvals, and account health. Several tools bundle multiple operations (handoff, people, schedule) which inflates the count, but the scope justifies a larger surface. Still, some consolidation—merging account_pulse with report, or inbox with conversation—would tighten the set.
Completeness3/5
The toolset covers the main lifecycle: create/read/delete posts, read/reply to conversations, manage people, schedule, and monitor spend/rate limits. However, key gaps exist: no update/edit post, no like/unlike or follow/unfollow (only handoff for human-doable actions), and no explicit tool for managing drafts beyond scheduling. This means some user intents will dead-end.
Average 4.3/5 across 23 of 23 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- 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.
Add a glama.json file to provide metadata about your server.
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 discloses a key behavior: 'publish(idea_id=…) marks one used so the next session does not repeat it,' which aligns with the idempotentHint=true annotation and adds stateful context. However, it introduces 'publish' as if it were an action though the schema only allows add/list/drop, which is misleading. Other behaviors like what 'drop' does or whether 'add' is idempotent are not covered. No direct contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (33 words) and ends with a clear action list, which gives it some structure. However, it opens with the cryptic 'Free, local.' and inserts a function-like notation 'publish(idea_id=…)' that disrupts flow and wastes words on an irrelevant or mistaken concept. It is compact but not efficiently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and minimal annotation coverage, the description carries heavy responsibility to explain inputs and side effects. It only addresses a few fields, omits crucial context like what 'drop' does, and incorrectly references a 'publish' workflow. The description is insufficient for an agent to correctly invoke all actions without additional guesswork.
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 only 14%, so the description must compensate, but it only loosely references source_url, format, and tags while omitting text and include_used entirely. Worse, it suggests a 'publish' action that does not exist in the schema, adding confusion rather than clarity. The description fails to meaningfully explain parameter roles or relationships beyond what the raw schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description indicates the tool parks and manages post ideas with source URL, format, and tags, and includes actions add/list/drop. However, the main verb is unclear and the mention of a non-existent 'publish(idea_id=…)' action confuses the purpose relative to the schema's enum. The title offers helpful context, but the description itself is vague and could apply to several different content-pipeline utilities.
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?
Usage is implied by the title 'content pipeline between scouting and publishing' rather than stated in the description. The description does not mention when to use this tool versus siblings like scout, publish, or draft_check, and gives no explicit when-to-use or when-not-to-use guidance. It is neither completely lacking nor helpful enough to distinguish from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and idempotentHint=true, but the description says the tool will 'append to the local snapshot history' and return velocity/milestones. Appending to a history implies a write side effect and repeated calls may accumulate history, contradicting the read-only and idempotent hints. This is an annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single overloaded sentence with nested clauses, semicolons, parentheses, and multiple thresholds. It is information-dense but poorly structured and hard to parse. It could be split into front-loaded purpose, parameters, side effects, and return semantics for better readability.
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 return values (velocity, corpus entry, cold-start lift, like milestones, aging out), side effects (snapshot history), costs, and important constraints like the 30-day limit. With no output schema, this return-value detail is valuable, though missing max semantics and possible response shape prevent a perfect score.
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 only 33% schema description coverage, the description compensates partially: it explains include_private_metrics, a cost difference, and the 30-day constraint on post_ids. However, max is entirely unexplained semantically; the description does not clarify what max limits (number of posts, history entries, etc.), so the low-coverage burden is not fully met.
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 opens with a specific action ('Pull current metrics for your posts') and a clear resource, then details the exact output ('return velocity + milestones'). It distinguishes itself from siblings like insights or account_pulse by focusing on algorithmic post health and concrete milestones.
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 gives clear context for when to use the tool: for own posts within 30 days, with instructions to set include_private_metrics when impressions/url clicks/profile clicks are needed. It does not explicitly name alternatives or exclusions, but the practical usage conditions are well stated.
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?
Description adds valuable context beyond annotations: it explains that writes are parked when approval mode is on, and clarifies the tool deliberately excludes approval to enforce human confirmation. Annotations already mark it idempotent and non-destructive, so the description enriches with queue semantics and CLI limitation.
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, with the second sentence clearly stating the agent's capabilities and limitation. The first sentence is somewhat awkward ('Writes park here') but still conveys relevant context about when the queue is used, earning its place without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should explain what the 'list' action returns, but it does not. It also fails to clarify whether 'reject' requires an id or how 'include_done' affects results. For a 3-parameter tool with no schema descriptions, this is incomplete.
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 carries the burden for parameter meanings. It only mentions 'list' and 'reject' as action values, but does not explain 'id' or 'include_done' – when they are needed, their format, or their effects. This is a significant 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?
Title clearly states 'list or reject queued API actions' and description confirms 'The agent can list and reject', providing a specific verb+resource+scope that distinguishes this tool from siblings which are about other domains (spend, publish, inbox, etc.).
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 states that approving is CLI-only ('x-mcp approve <id> or x-mcp approve --all'), guiding the agent not to attempt approvals through this tool. It also explains when the queue is active ('when approval mode is on (the default) or when force was used'), giving clear context for 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, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond these: it enumerates the exact rules evaluated (URL weights, spam triggers, engagement-bait patterns) and confirms there are no side effects. It also mentions 'concrete suggestions,' though it does not elaborate on output format. Since annotations carry the safety profile, the description earns credit for enriching the behavior picture.
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 dense sentence packed with specific metrics and rules, each earning its place. It is front-loaded with the core action ('Run the algorithm rules engine on a draft') and immediately provides actionable details. While dense, there is no fluff; even 'Costs nothing' is a useful differentiator. The length is appropriate for the technical specificity.
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 4 parameters, no output schema, and moderate complexity, the description explains the scoring logic thoroughly but omits return value format (score, warnings, suggestions shape). It also does not clarify how 'kind' affects scoring despite listing reply/quote weights. Annotations help, but with no output schema, the description should describe what the agent receives, which is missing. Still, it provides enough workflow context (score ≥80) to be partially 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?
Schema description coverage is 50% (limit and variants have descriptions). The main description adds some context by implying that 'draft' refers to the text parameter and mentions weighted length and mention counts tied to text content. However, it does not explain the 'kind' enum's impact on scoring (though it hints 'reply 5→20') or the purpose of 'variants' beyond an implicit side-by-side comparison. It partially compensates but does not fully bridge the gap for undocumented 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 tool's purpose: 'Run the algorithm rules engine on a draft' and lists specific checks (weighted length, mentions, URL cost, engagement-bait, hashtags, ranking heads). It also provides a concrete workflow ('Iterate until score ≥ 80'), distinguishing it from sibling tools like publish or reply, which are actions rather than assessments.
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 implies usage by instructing 'Iterate until score ≥ 80 with no warnings, then publish,' establishing a clear pre-publish check workflow. It also notes 'Costs nothing,' which differentiates it from potential paid alternatives. However, it does not explicitly name alternative tools or state when not to use it, so it misses explicit exclusions.
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, idempotentHint=true, destructiveHint=false, so the description doesn't need to repeat safety. It adds useful behavioral context: it's free and local, aggregates own posts, and depends on snapshot freshness (refresh with post_performance). This goes beyond annotations by explaining the data dependency and how to improve accuracy.
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, dense paragraph that front-loads the core value ('Free, local. Aggregates...') and then lists metrics. It's long but every sentence adds value; the list of metrics is necessary to convey the tool's scope. Could be slightly more structured with bullet points, but it's acceptable for a description.
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 (many metrics, dependency on snapshots and tags), the description covers the key aspects: what it does, how to improve it (tag posts, snapshot), and the optional 'days' parameter. No output schema exists, but the description lists the outputs (metrics) in detail, so the agent knows what to expect. It doesn't mention edge cases like empty data, but that's minor.
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 description coverage is 100% (the only parameter 'days' has a description: 'Window (default 30).'). The description doesn't add much beyond that, but it does mention 'best posting hours' and 'top posts' which relate to the time window. Baseline 3 is appropriate since the schema already documents the parameter adequately.
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 aggregates user's own posts and metric snapshots into business-relevant analytics, listing specific metrics (originals/replies/threads, OON-entry rate, engagement by kind/tag, best hours, etc.). It distinguishes from siblings by emphasizing 'free, local' aggregation and the need to refresh with post_performance, which is unique among the listed tools.
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 implies when to use it (to get business-watching numbers) and mentions a dependency on post_performance for refreshing snapshots, plus tagging posts for sharper insights. It doesn't explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to decide.
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, idempotentHint=true, and destructiveHint=false, so the safety profile is well-covered. The description adds valuable context: it works offline ('No network'), aggregates multiple data sources, and returns a ranked list. This goes beyond the annotations by explaining the tool's scope and behavior without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the key fact ('No network') and then enumerates the inputs and output. Every clause adds value, and it ends with a clear usage directive. 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 tool's complexity (aggregating many data sources) and the lack of an output schema, the description does a good job of explaining what it considers and what it returns. It could mention the return format (e.g., list of strings or objects) but the phrase 'prioritised list of concrete next calls' is sufficient for an agent to understand the output. The single optional parameter is well-defined in the schema.
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 schema has only one optional parameter (limit) with a clear range (1-20), and schema description coverage is 0%. The description doesn't mention the limit parameter, but since it's optional and self-explanatory, the baseline of 3 is appropriate. The description focuses on the tool's behavior rather than parameter details, which is acceptable given the minimal parameter surface.
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: it returns a prioritized list of concrete next calls based on local state. It lists specific inputs (unanswered inbound, due scheduled posts, etc.) and explicitly notes it works without network. This distinguishes it from siblings like 'inbox' or 'schedule' by framing it as an aggregator/prioritizer rather than a single-resource tool.
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 when to use it: 'Call it whenever you finish a step.' It implies it's a general-purpose next-action recommender, which differentiates it from more specific tools. However, it doesn't explicitly state when NOT to use it or name alternative tools, though the context makes it clear it's the go-to for deciding what to do next.
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: the opt-in enforcement mechanism, cost per event, fixed cost, throttle rate, and force bypass with human approval. No contradiction with the provided 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?
Three tight sentences deliver essential information without fluff. Each sentence adds value: the core rule, the force exception, and pricing/limits. Front-loaded with the action.
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?
Core behavior and safety constraints are well covered, but with five parameters and no output schema, critical details like identifying the recipient and the meaning of 'reason' are underexplained. The description is adequate but not fully 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?
Schema description coverage is only 20% (force only). The description adds throttle/cost info but does not explain how to specify the recipient (user_id vs username), the required 'text' parameter, or the optional 'reason' parameter, leaving a substantial 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 action ('Send a DM') and the resource (direct message). It distinguishes from siblings like 'inbox' and 'reply' by highlighting the opt-in-only constraint and the explicit focus on direct messages.
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 concrete guidance on when the tool is allowed (only after the recipient DM'd you first) and explains the force bypass. However, it does not explicitly mention alternatives or when to prefer this over sibling tools like 'reply'.
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 goes beyond the annotation hints by explaining the local persistence model, what data is tracked, that note/tag memory persists into the next session, and the side effect of queue=true creating handoff(follow) items. It does not describe return values, auth limits, or rate limits, but it is not misleading and does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but scannable, using a clear lead-in and a short bullet-style breakdown of actions. Every sentence adds operational value such as weight formulas, persistence behavior, and the scout pairing; there is no filler or repetition of schema declarations.
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 multi-action tool with no output schema, the description is strong enough to guide action selection and provide useful mental models for invite: list valuation, the note/tag persistence, and the handoff-queue side effect. The main completeness gap is the absence of precise filter-band semantics and what the returned records contain per action.
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 strong meaning for the action values, especially the top scoring formula and suggest_follows trigger rule. However, with only 33% schema description coverage, meaningful gaps remain: limit is not explained, and the filter enum values such as peer_small, mid, and large have no threshold 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 title immediately frames this as a relationship ledger/CRM, and the description names specific verbs and resources: top, get, note, tag, and suggest_follows. It is clearly distinguished from feed- or discovery-style tools such as inbox and scout by focusing on per-person engagement history and follow-back optimization.
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 concrete guidance on when to use suggest_follows and recommends pairing with scout(circle=true) to find posts to engage with. It does not explicitly state when not to use this tool versus siblings like inbox, who, or conversation, so it misses the highest level of exclusionary 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?
The description transparently discloses that scheduling does not post immediately and that posts only go out when run_due is executed. It also notes that due posts go through the normal publish pipeline, providing insight into side effects. This goes beyond the annotations, which only state readOnlyHint false, by explaining the deferred execution model.
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 (about three sentences) yet packs essential information: the core behavior, the 'when' formats, the list of actions, and the condition for posting. It uses parentheses effectively to clarify sub-points without verbosity.
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 moderate complexity (multiple actions, a nested 'post' object), the description covers the main behavior and actions sufficiently. It does not detail edge cases or error handling, but within the provided context it is complete enough for an agent to understand the tool's function and main 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 description coverage is only 40% (only 'post' and 'when' have descriptions). The tool description adds useful semantics for the 'when' parameter (ISO, relative formats, next_best) and clarifies the 'action' enum values, but parameters like 'include_done' and 'id' remain unexplained. The description partially compensates for the schema gaps but not fully.
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: to queue posts for later publishing, with actions like add, list, cancel, run_due, and best_times. It explicitly mentions that nothing posts until run_due is called, distinguishing it from immediate publishing tools.
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 implies when to use this tool by contrasting with immediate publishing ('Nothing posts until run_due is called') and by listing the available actions. It does not explicitly name alternative tools, but the behavioral distinction is clear enough for an agent to choose this for scheduling.
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, idempotentHint=true, and destructiveHint=false, so the tool is known to be safe. The description adds context about what is shown (token state, identity, scopes, config with secrets redacted, rate-limit snapshot, API boundary), which goes beyond annotations by explaining the output contents and the redaction of secrets. It does not contradict annotations; it enriches them. It could mention the optional network call and its cost, but that is covered in the parameter 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?
The description is a single, information-dense sentence that lists all the diagnostic outputs without fluff, followed by a clear directive. It is front-loaded with the primary purpose and uses punctuation to separate items. Every word earns its place, and it is not overly long or verbose.
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 health-check tool with no output schema, the description explicitly enumerates the six categories of information it returns (token state, identity, scopes, config, rate-limit snapshot, API boundary). The optional network call and its cost are documented in the schema. The description is complete for the tool's purpose and leaves no major gaps about what the tool will do or provide.
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 only parameter 'verify_network' is fully described in the schema (100% coverage) including its behavior (calls users/me) and cost. The main description does not discuss the parameter, which is acceptable because the schema carries the semantic load. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Health check: auth, scopes, config, rate limits, API boundary' and description clearly state the tool's purpose: to display diagnostic information about OAuth state, identity, scopes, config, rate limits, and API boundary. It uses specific verbs (shows, run when something fails) and is distinct from sibling tools which are action-oriented (publish, dm, delete_post) or financial (spend, approvals), making it unambiguous.
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 says 'Run when something fails,' providing a clear trigger for use. It does not mention exclusions or specific alternatives, but given that no sibling tool performs health checks, this is sufficient. A stronger guideline would mention use cases like preflight checks or debugging before contacting support, but the basic directive is present.
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 include readOnlyHint: false and destructiveHint: false, which the description is consistent with. It adds substantial behavioral context: the reconcile mechanism (detecting completion via owned reads), the algorithmic impact (quote posts as originals, follows creating mutuals), and the action-specific behaviors (done/drop mark manually). This goes beyond the annotations to explain side effects and automation logic.
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 well-organized with bullet-style sub-actions and a separate 'Why this matters' section. It front-loads the main purpose in the first sentence, then details each action. It is moderately long but every part adds value—the algorithmic reasoning helps the agent decide when to call this tool. No wasted words, though some redundancy with the schema enum values exists.
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 complexity (8 parameters, 5 action types, no output schema), the description provides a strong overall picture: it explains the workflow, the reconcile logic, the algorithmic importance, and the division of responsibility. It doesn't specify the return format or error handling, but for a queue-management tool with these annotations and schema hints, it is sufficient for an agent to know how to invoke it and what to expect.
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 covers only 50% of parameters with descriptions (id, why, text, target_username have descriptions; kind, action, include_done, target_post_id lack textual descriptions). The description compensates by clarifying the role of these parameters in the context of each action (e.g., text as drafted post/reply text, target_username as author handle required for follow, id for done/drop). It also explains the 'kind' enum values and their algorithmic significance, adding meaning beyond the raw schema.
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: 'Manage the queue of actions only a human can do on a pay-per-use account.' It enumerates specific sub-actions (add, list, done/drop, reconcile) with concrete semantics, and distinguishes itself from siblings by focusing on the human handoff queue for restricted actions.
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: for actions that require human intervention due to platform restrictions (X removed follows, likes, quote-posts, un-summoned replies). It states 'The agent drafts; the human taps,' clearly indicating the division of labor. It does not explicitly list alternative tools for when not to use it, but the platform restriction context makes the appropriate usage obvious.
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, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds useful context that the report is free, local, and returns markdown, which goes beyond what annotations provide.
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 key qualities (free, local) and then the purpose and composition. Every sentence earns its place without repetition.
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 read-only tool with one optional parameter, the description is complete: it says what the report is, what it includes (built from insights, people, handoff, goals), and the output format (markdown). No output schema exists, but the description sufficiently conveys the return value.
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 only parameter 'days' is fully described in the schema with a default and range, so the description need not repeat it. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool produces a markdown report for the account owner, and the title lists specific contents (followers, output, what worked, people, queue, goals, advice). It distinguishes itself from sibling tools by aggregating insights, people, handoff, and goals into a single digest.
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 a clear use case: generate a weekly summary or shareable report, mentioning it can be pasted into DM/email/Notion. It doesn't explicitly name alternative tools for raw data, but the aggregate nature implies when this tool is appropriate versus querying individual data sources.
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 details beyond annotations, such as 'set (merge)' indicating merge semantics, and notes that banned words are 'flag[ged]' by draft_check and publish. It also mentions persistence and local/free attributes. These go beyond the boolean annotations (readOnlyHint:false, idempotentHint:true, destructiveHint:false) without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long yet packs in free/local, persistence, the list of constraints, relationships to other tools, and the three actions. Each clause adds value, and the structure flows from high-level purpose to specific actions. 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?
For a tool with nested goals and multiple arrays, the description covers the main aspects: what the brand book contains, that it persists, and the three actions. It does not describe the return format of 'check', but with no output schema required and the low-level schema having moderate documentation, this is acceptable. The description is largely complete for an agent to understand when and how to use the 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?
With schema coverage at only 38%, the description compensates by explaining the 'set (merge)' behavior, the roles of banned words and goals (e.g., 'followers by date, originals per week'). It also clarifies that 'check' takes a draft as input, mapping to the 'text' parameter. This adds meaning beyond the raw schema properties.
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 manages the 'account's operating constraints' including lane, voice, banned words, and goals, and lists explicit actions (get, set, check). It distinguishes itself from siblings like draft_check and publish by positioning itself as the persistent brand book that those tools reference. This is a specific verb+resource with clear scoping.
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?
Context is provided that the brand book is used by 'draft_check and publish' and that goals are tracked by 'insights/report'. The description implies when to use this tool (e.g., to set or check brand constraints) but does not explicitly state when-not or mention alternatives. It gives clear context without exclusions, so a 4 is appropriate.
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?
Adds important details beyond annotations: irreversible action, cost ($0.01), approval queue behavior, and the whole edit chain deletion. These are not present in the readOnly/destructive/idempotent hints.
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-loaded with the purpose, and each sentence adds distinct information without redundancy.
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 simplicity and lack of output schema, the description covers all relevant aspects: scope, force behavior, approval, cost, irreversibility, and edit chain effects, leaving no major gaps.
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 covers force and confirm with descriptions, but post_id has no description and the tool description does not clarify it. Since schema coverage is only 67% (below 80%), the description fails to compensate for the missing parameter detail.
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 the action: 'Delete a post you authored' and specifies the scope (only posts the server knows as yours, with a force option). Distinguishes from sibling tools by focusing on deletion rather than publishing, reposting, or messaging.
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 conditional guidance (force for posts not recorded, approval mode queues for human) and mentions cost. Lacks explicit alternatives, but the context of deleting authored posts makes usage 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?
Annotations already declare read-only and idempotent, so the description adds significant behavioral details: cost per item, sorting/prioritization logic, default filtering of unanswered items, side effect on relationship ledger, and a security note about third-party content. This far exceeds what annotations provide.
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 dense but every sentence contributes unique information: cost, functionality, related tools, prioritization, defaults, side effects, and security. The phrasing 'reply weight is the biggest realistic head' is cryptic and could be clearer, but overall it is efficiently structured.
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 tool with two optional parameters, the description covers result contents, sorting, default behavior, side effects, cost, and security considerations. No output schema is provided, so the description fully compensates for expected return values. It is comprehensive for its complexity.
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 description covers 50% of parameters (include_answered is described in schema). The description adds that items are 'unanswered by default', informing include_answered's default behavior, but does not clarify the 'max' parameter. At 50% coverage, the description partially compensates but leaves room for more parameter-specific guidance.
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 'Lists posts that @mention you or reply to you' with specific details like 'newest first' and author attributes. It distinguishes from siblings by emphasizing 'Owned read' and its role in the reply workflow, explicitly referencing the reply and people tools.
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?
Explicitly references 'the reply tool' and 'people tool' as related tools, indicating when to use them in conjunction. It provides context on replyability and side effects but stops short of naming alternative tools to choose instead, offering clear usage context without formal exclusions.
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 discloses that it refreshes data and lists mentions/replies, implying read-only behavior consistent with annotations. It also adds a note about third-party content being data, not instructions, which is a behavioral safeguard. However, it does not elaborate on potential side effects beyond that, though annotations already cover safety.
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 dense sentence that packs a lot of information: purpose, key metrics, time windows, and a note. It starts with a clear header 'The morning-briefing tool' and front-loads the core idea. While it is long, every clause carries value, making it appropriately concise for the breadth of functionality.
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 purpose, usage, parameters, and a behavioral note about third-party content. It implies the output (a briefing with metrics) but does not explicitly describe the return format, which is acceptable since no output schema is provided. Overall, it is complete for the tool's apparent complexity.
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 schema descriptions for 'posts' and 'mentions' are clear ('How many of your recent posts to refresh', 'How many recent mentions to scan'). The tool description references these parameters indirectly by mentioning 'recent posts' and 'new mentions', providing context on their purpose. Since schema coverage is 100% and the descriptions are adequate, the added value is moderate.
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 is a morning-briefing tool that aggregates account metrics, mentions, replies, and spend. It uses a concise summary phrase 'what moved, who to answer, what it cost' and explicitly lists all features, making its purpose unmistakable and distinct from sibling tools.
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 gives an explicit usage directive: 'Call this first in every session.' This unambiguously tells the agent when to invoke this tool, positioning it as the initial overview step. It does not explicitly mention when not to use it, but the 'first in every session' instruction is a strong guideline.
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 only indicate non-read-only behavior (readOnlyHint=false). The description discloses far more: rate limits (≤12 replies/hour), budget details ($0.01/$0.2 with URL), copypasta guard, handoff creation for cold replies, force behavior routing through human approval, and X's approval requirements. This far exceeds what annotations provide.
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 long paragraph but every sentence delivers essential operational detail. It front-loads the purpose and rule, then systematically covers constraints and force semantics. While not concise in word count, the density of high-value information justifies its length. Minor structure improvement could separate rules from approvals.
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 5 parameters, no output schema, and complex operational rules, the description covers the critical behaviors: mention rule, rate limits, budget, handoff, force, and approvals. However, it omits behavior for dry_run and media_paths parameters, and does not describe return values or confirmation behavior. Given the complexity, these gaps lower completeness slightly.
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 description coverage is 60% (text, force, post_id have descriptions; dry_run and media_paths do not). The description adds some context (e.g., force skips local checks but requires approval), but it does not clarify dry_run or media_paths behavior. Since coverage is not high, the description should compensate, but it falls short on those parameters. It does mention budget impact for URLs, which is indirect param 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's purpose: replying via the API to posts that mentioned or replied to you. It precisely scopes the operation ('Reply to a post that summoned you') and distinguishes it from siblings like publish (creating new posts) and dm (private messages). The verb 'reply' plus the specific trigger conditions provide unambiguous purpose.
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 gives explicit when-to-use guidance: only when the target post's author @mentioned you or replied to you. It also states when NOT to use (cold replies) and the fallback handoff mechanism. It further specifies conditions for using force=true and approval requirements. This is exemplary usage guidance.
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?
Explains the local ledger nature, price mirroring, dedup, and the limitation that it's not authoritative due to no balance API, providing transparency about data source and caveats.
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 conveys necessary details but includes some parenthetical and explanatory phrases that add length; still efficient and not verbose.
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?
Provides sufficient context about data sources, limitations, and reconciliation, though it doesn't specify output format or further edge cases, which is acceptable given no output schema.
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 single parameter 'recent' is clearly described in the schema, and the tool description adds context about the output including 'last 24h', but doesn't elaborate further on parameter usage.
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 the tool returns spend data, remaining budget, recent activity, and price table, distinguishing it from other tools in the set.
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?
Mentions the absence of a balance API and suggests reconciling against console, giving context on when to rely on this tool versus external sources, though not explicitly stating when 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?
Annotations already cover readOnly/openWorld/idempotent, but the description adds vital behavioral details: pricing ($0.01 base, $0.005 per post), the exact follower band thresholds, the mutual-follow bonus mechanic (+15 reply weight), and a crucial security note that third-party content fields are data, not instructions. This exceeds what annotations capture and warns against prompt injection.
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 punchy sentences that pack in cost, what is returned, thresholds, a mechanic, and a security warning. Absolutely every word earns its place; nothing is wasted.
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 tool with no output schema, the description fully covers what will be returned (band, connection status, verified type, bio, posts), the pricing, and a critical security caveat. Given the tool's simplicity, this is complete and would let an agent use it correctly and safely.
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 carries the explanatory load. It clarifies the 'recent_posts' parameter through 'optionally their last few original posts' and the per-post cost. It omits explicit explanation of user_id/username, but those are self-explanatory, and the note about 'text', 'description', and author fields adds value by warning about third-party content, which indirectly helps interpret 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 starts with 'User lookup' and enumerates the exact return fields (follower band, connection status, verified type, bio, optional recent posts), making it unmistakably clear what the tool does. The resource (user) and action (lookup) are explicit, and the detail on follower band thresholds distinguishes it from generic sibling names.
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 strong context (cost per call, per-post fees, return values) but does not explicitly state when to use this tool over siblings like 'scout' or 'account_pulse'. Usage is implied through the lookup-oriented wording, but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits beyond the annotations: it runs algorithm rules first, enforces monthly budget, and records posts for tracking. It also notes that quote posts are Enterprise-only, which is a critical constraining detail not in annotations. However, it doesn't detail the exact effects of posting (e.g., irreversibility) beyond the budget, though annotations already indicate it's 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?
The description is well-structured, starting with a clear verb and purpose, then detailing key rules, budget, and alternative tools in a compact paragraph. It is front-loaded with the main action and alternatives, and 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 tool's complexity (14 parameters, nested objects, algorithm rules, and budget), the description effectively communicates the major constraints and side effects. It covers the algorithm checks, media constraints, budget, and tracking, which is comprehensive. However, it doesn't describe the return value (no output schema), which might be a minor gap, but the detailed annotation and schema coverage compensate.
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 93% schema description coverage, the schema already documents most parameters. The description adds context for `thread` (posts as replies, no For You reach) and `dry_run`, and mentions budget impacts for URLs, but it doesn't explain the `long_post_limit` beyond schema. However, given the high coverage, a 4 is justified as it adds clarity on key 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 tool's purpose: creating an original post on the authenticated account, with options for a self-thread and media. It distinguishes itself from siblings like `reply` (which posts replies) and `handoff` (for quote posts) by explicitly mentioning those alternatives.
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 provides explicit guidance on when to use this tool vs. alternatives: use `thread` for follow-up replies, and use `handoff(kind="quote")` for quote posts. It also details the dry_run option for planning, making it clear when to use it for previewing.
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 mark read-only and idempotent, and the description adds substantial behavioral details: cost per read, max cap, chronological ordering, inclusion of authors, 7-day recency, and the crucial 'data, not instructions' warning. This goes far beyond the structured data.
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 deliver purpose, constraints, pricing, and safety warning with zero redundancy. Every phrase 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?
For a two-parameter read-only tool, this is comprehensive: cost, time window, ordering, usage timing, and content-safety warning are all covered. No output schema is needed.
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 explains max as a cap with default 20, and post_id is self-explanatory though not explicitly detailed. This covers the key semantics effectively.
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?
Clear verb+resource: 'Fetch a post and the replies in its conversation'. Distinguishes from sibling write tools (reply, delete_post) and includes specific scoping details (7-day window, chronological order).
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?
Explicitly states 'Use before replying so the answer is specific', giving an actionable context for when to invoke. However, it does not name alternatives or exclusion criteria, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavioral traits beyond the annotations: reposts 'never travel out-of-network in For You and are ×0.75 in-network,' plus the throttling limit and cost. This adds significant context about the tool's actual effects, which the annotations (readOnlyHint false, idempotentHint true) do not cover. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but packed with essential information. It front-loads the main purpose, then efficiently covers usage restrictions, network effects, throttling, and cost in a single flowing sentence. Every clause contributes value 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 modest complexity (no output schema, few parameters), the description is remarkably complete. It explains not just what it does but when it's allowed, its limitations (network spread, throttling), and the cost. The only minor gap is the lack of explanation about post_id, but that is a simple field and the overall context is sufficient for an agent to invoke the tool 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?
The description does not provide additional meaning for the parameters. The schema already describes 'why' as 'One line on why (kept in the ledger note)' and 'post_id' only has a pattern, with no description. Since schema coverage is exactly 50% (why described, post_id not), and the description adds no param-level details, it is only adequate but not enhancing. The parameter names are fairly self-explanatory, but the description does not compensate for the missing post_id description.
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: 'Repost another post to your followers.' This is a specific verb (repost) and resource (a post), fully distinguishing it from siblings like publish, reply, or dm. It also adds context about the action's network distribution and throttling, further clarifying what it does.
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 says when to use the tool: 'Allowed on pay-per-use for informational sharing (no bulk)' and 'use sparingly, mainly to amplify people who engaged with you.' It also notes constraints like 'Throttled to 10/day' and cost, giving the agent clear guidance on appropriate usage versus 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?
Annotations declare readOnlyHint=true and destructiveHint=false, and the description adds substantial behavioral context: the 7-day window, cost per post ($0.005), hard cap of 100, deduplication per UTC day, default filters, and the advisory that third-party content is data not instructions. It fully discloses behavior without contradicting annotations, going well beyond what structured data provides.
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 dense but efficient, front-loading the core purpose and then covering ranking criteria, constraints, and alternatives in a logical flow. Every sentence contributes new information (costs, dedup, default filters, data-safety note), with no fluff or redundancy.
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 lack of an output schema, the description thoroughly explains what the results contain (author follower band, freshness, question-ending, engagement, reply status) and the operational constraints (costs, caps, dedup, defaults). It also addresses edge cases (raw=true, circle=true) and safety (third-party content). For a tool with 8 parameters and no output schema, this is exceptionally complete.
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 88% (7/8 params described; 'sort' lacks a description). The description adds valuable context beyond the schema, such as the meaning of max_followers (e.g., '60000 to avoid LLM-scored threads') and the purpose of circle=true, enriching parameter understanding. However, not all parameters are elaborated in prose, so it doesn't fully compensate for the missing sort description.
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 action ('Search recent posts with X operators') and its resource (recent posts within a 7-day window) and purpose (rank as opportunities). It distinguishes itself from sibling tools like 'people' and 'conversation' by focusing on opportunity ranking and mentions the handoff mechanism for cold replies, making its niche explicit.
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 provides explicit when-to-use guidance: using circle=true for own community and handoff for cold replies. It also states default filters and the inability to cold-reply via API, steering users toward the right alternative. This is a model of usage clarity, with both context and exclusions.
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-mcp MCP server](https://glama.ai/mcp/servers/rthomas24/x-mcp/badges/card.svg)](https://glama.ai/mcp/servers/rthomas24/x-mcp)

Score Badge

Copy to your README.md:

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

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/rthomas24/x-mcp'

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