ShipPost MCP

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation4/5
Most tools are clearly distinct (get_tweet vs get_timeline vs get_mentions), but get_my_profile and get_user_profile could be confused if not for the 'my' vs 'user' distinction. The draft_* tools are distinct from post/reply actions.
Naming Consistency4/5
Tools follow a consistent verb_noun pattern (get_*, post_*, reply_to_*, like_*, retweet, follow_*, draft_*, analyze_*, find_*). Minor deviation: 'retweet' lacks an underscore but is still clear and consistent with the action.
Tool Count4/5
17 tools is slightly above the ideal range but appropriate for a Twitter client with both standard actions and AI-assisted features. Each tool serves a distinct purpose, though some could be consolidated (e.g., draft_tweet and draft_thread).
Completeness4/5
Covers core Twitter operations (read, post, reply, like, retweet, follow) plus analytics and AI drafting. Missing delete_tweet, unfollow, and block/mute, but the main engagement workflow is complete. The AI features add value beyond basic CRUD.
Average 3.8/5 across 17 of 17 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Follow' with no mention of side effects, authentication requirements, rate limits, or reversibility. For a mutation tool, this is insufficient.
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, clear sentence with zero fluff. It is appropriately sized for the tool's simplicity and front-loads the core action 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?
Given the tool's simplicity (one parameter, output schema present), the description conveys the basic action adequately. However, it lacks any nuance about usage context or effects that one might expect even for a simple mutation, leaving it minimal but functional.
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 covers 100% of the parameter details (username without @), so the description adds no additional meaning. However, the baseline for high coverage is 3, and the description does not detract from the schema but also does not enhance 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 action ('Follow') and the resource ('a Twitter user'), which is specific and distinguishes it from sibling tools like like_tweet or retweet. It is not a tautology and directly conveys the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. With 16 sibling tools including similar actions, the lack of any contextual comparison is a significant gap.
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?
There are no annotations, so the description carries the full burden for behavioral disclosure, but it only restates the action itself. It does not mention authentication requirements, idempotency, side effects like unlike behavior or rate limits, or behavior when the tweet is already liked.
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 words long, wholly waste-free, and front-loaded with the action immediately. For a simple one-param tool like this, the concise structure is appropriate.
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 extremely simple schema and one required parameter, the definition is minimally viable: the agent knows the action and the input. However, the complete lack of behavioral or usage context leaves gaps around preconditions, edge cases, and what happens on execution.
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 fully describes the only parameter (tweet_id) at 100% coverage, so the description needs little additional parameter detail. The description adds no extra semantic nuance, but the schema already handles this dimension.
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 is unambiguous: the verb 'Like' and resource 'tweet' clearly identify exactly what the tool does. It is also distinct from the sibling tools such as retweet, post_tweet, reply_to_weet, or follow_user.
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 guidance is provided about when to use this tool, when not to use it, or how it compares to alternative actions. The agent is left to infer usape from the sibling list and the action name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action without mentioning public visibility, side effects, or permission requirements, which are relevant for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a single, direct sentence. It is not verbose, and the phrasing is clear, though it could include slightly more context without becoming bloated.
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 low complexity (one parameter) and the existence of an output schema, the description is minimally sufficient. However, it lacks any mention of authentication requirements or the fact that the retweet becomes public, which would improve completeness.
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 covers the single parameter (tweet_id) with a clear description, so the description adds no additional detail. At 100% coverage, 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 description clearly states the verb 'retweet' and the resource 'a tweet', which is specific and distinguishes from siblings like post_tweet, reply_to_tweet, and like_tweet. It unambiguously identifies the action.
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 provides no guidance on when to use this tool versus alternatives. There is no mention of scenarios, prerequisites, or exclusions, leaving the agent to infer usage solely from the action name.
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 are absent, so the description carries the burden. It states that it returns tweets with text, author, engagement metrics, and URLs, which gives some behavioral insight. However, it does not disclose any pagination behavior, authentication requirements, or rate limits, which would be common for a read operation that might have pagination.
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 main action, and includes a return-value summary. Every sentence adds value, and there is no 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?
For a simple read operation with a single fully described parameter and an output schema, the description is nearly complete. It could mention pagination or the nature of the timeline, but given the simplicity and the presence of an output schema, it is sufficient.
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 has one parameter (max_results) with 100% description coverage, so the schema already explains it. The description does not add much beyond that, but the baseline of 3 is elevated to 4 because the schema is fully covered and the default is described, making the description unnecessary for parameters.
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 it retrieves recent tweets from the user's home timeline, which is specific and distinct from siblings like get_mentions or search_tweets. However, it does not explicitly contrast with siblings, but the resource and scope are clear.
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?
It says 'Use this to see what's happening in the user's feed,' which implies usage context, but it does not mention when not to use it or suggest alternatives (e.g., for mentions or specific tweets). This is adequate but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention that this is a read-only operation, any authentication requirements, rate limits, or what happens if the user is not authenticated. The description only states what it gets, without any side-effect or behavioral notes. Since it's a 'get' operation, the read-only nature is implied but not explicitly disclosed.
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, concise sentence that front-loads the action and resource. It provides a clear and efficient explanation without any filler. Every word adds value, and it does not repeat information already in the schema or tool name.
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 simple tool with no parameters and an output schema (which likely documents the return structure), the description is nearly complete. It covers what the tool does and what data it returns. However, it omits any mention of authentication prerequisites or when this tool is appropriate, which slightly reduces completeness. Given the tool's simplicity, this is adequate.
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 tool has zero parameters, and the schema confirms that (empty properties). Per the rubric, with 0 parameters the baseline is 4. The description doesn't need to add parameter info, so a score of 4 is appropriate. The description's mention of specific fields (name, bio, follower count, tweet count) adds a bit of context but is not necessary for 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 'Get the authenticated Twitter user's profile', specifying the exact resource and verb. It distinguishes from sibling get_user_profile by specifying 'authenticated user's', making it clear this is for the current user's own profile. The fields listed (name, bio, follower count, tweet count) further clarify the scope.
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 usage context is implied by the phrase 'authenticated user's', but there is no explicit guidance on when to use this tool versus alternatives like get_user_profile. No exclusions or conditions are mentioned. The description doesn't direct the agent to choose this over get_user_profile for own profile, nor does it mention any prerequisites such as being logged in.
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?
With no annotations provided, the description carries the full burden. It discloses an authentication requirement and hints at the output ('Shows which tweets performed best'), but does not explicitly state whether the operation is read-only, mention rate limits, or detail any side effects. The 'Get' verb implies a safe read, but it is not explicitly confirmed.
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 concise sentences: a clear purpose statement, an elaboration of what it shows, and a necessary authentication note. It is front-loaded with the core function and contains no unnecessary words or repetition.
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 simple tool with one optional parameter and an output schema, the description covers the essential aspects: what it does, the auth requirement, and the type of results. It lacks explicit comparison to sibling tools, but that is captured under usage guidelines. Overall, it is reasonably complete 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?
The only parameter (days) is fully described in the input schema with 'Number of days to analyze (default 7)', achieving 100% schema coverage. The tool description itself adds no additional meaning about the parameter, so it does not go beyond the 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 function with a specific verb and resource: 'Get engagement analytics on your recent tweets.' It further elaborates with 'Shows which tweets performed best, what's working, and trends,' which differentiates it from sibling tools like get_timeline or get_mentions by focusing on performance analytics rather than raw content.
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 context by focusing on recent tweets and engagement analytics, but it does not explicitly state when to use this tool over similar siblings like analyze_account. It does provide a prerequisite ('Requires a ShipPost API key'), but this is an operational requirement rather than guidance on tool selection.
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?
With no annotations, the description must carry the behavioral disclosure burden. It does add useful context about the returned data (full text, author, engagement metrics, conversation context), but it omits other behavioral aspects like error handling, authentication requirements, or read-only confirmation.
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 filler. Every word contributes either to what the tool does or what it returns.
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 simple single-parameter retrieval tool with an output schema, the description is largely complete. It states the lookup mechanism and the kinds of data returned. While it could benefit from usage-vs-alternative guidance, the simplicity reduces the need for more.
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% for the single parameter tweet_id, and the description only echoes 'by its ID' without adding further semantic detail. The baseline of 3 applies because the adjacent 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 uses a specific verb ('Get') and resource ('a specific tweet') with a clear retrieval method ('by its ID'). This sharply distinguishes it from sibling tools like get_timeline, get_mentions, and search_tweets, which have different scopes.
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 when you have a tweet ID and need details, but it does not explicitly state when to prefer this over alternatives like search_tweets or get_timeline. No exclusions or comparison guidance is provided.
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?
With no annotations provided, the description carries the full safety and side-effect burden. It does disclose meaningful behavioral traits: the tweet will be posted immediately and become publicly visible from the authenticated user's account. However, it does not mention irreversibility, rate limits, or potential posting failures.
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 short sentences and entirely front-loaded. The first sentence states the core action, while the second adds important side-effect context without any 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 one-parameter tool with a clear public side effect and an output schema, the description is mostly complete. It communicates the key facts: who performs the action, what happens, and when visibility occurs. It could be more thorough about limitations or exclusions, but overall it is sufficient.
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 already provides 100% coverage by describing 'text' as 'The tweet content (max 280 characters)'. The description adds no additional parameter-level semantics, but the schema alone is sufficient for a single simple 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 verb and resource: 'Post a tweet from the authenticated user's account.' It is specific enough to distinguish this tool from siblings like draft_tweet, reply_to_tweet, and retweet by implying a brand-new, instantly published 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 implies usage for creating and immediately publishing a tweet, and the 'immediately and publicly visible' phrasing gives useful context. However, it does not explicitly state when not to use it or name alternatives such as draft_tweet or reply_to_tweet.
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?
No annotations are provided, so the description carries the behavioral disclosure burden. It usefully discloses that the reply is public and posted from the authenticated user's account, but it does not mention potential failure modes, rate limits, irreversibility, or other side effects. Basic context is present, but richer behavioral transparency is missing.
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 short sentences with no filler. The first sentence is a clear one-line summary, and the second adds the important public/authenticated context. Every word earns its place.
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 low-complexity tool with only two parameters and an output schema, the description is mostly complete: it states the action, the public nature, and the authenticated account context. It lacks explicit usage exclusions, but the simplicity and schema coverage compensate, leaving only minor 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?
The input schema has 100% description coverage for both parameters (tweet_id and text), so the schema already carries the parameter meaning. The description adds little beyond 'given tweet' and 'reply text,' which does not meaningfully exceed the schema's existing explanations.
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 ('Reply to a specific tweet') and resource ('the given tweet'), and adds that it posts a public reply from the authenticated user's account. This distinguishes it from siblings like post_tweet or draft_reply by focusing on replying to an existing 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 implies when to use this tool—when replying to a specific tweet—but does not explicitly contrast it with alternatives like post_tweet (new tweet) or draft_reply (drafting without posting). There is no when-not-to-use guidance or named alternative tools.
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?
No annotations are present, so the description carries the burden of behavioral disclosure. It appropriately reveals the API key requirement (SHIPPOST_API_KEY) and the nature of the output, but it does not explicitly state that the operation is read-only, mention rate limits, or describe error behavior for invalid usernames. The output schema covers return structure, so the gap is moderate.
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: purpose, use case, and auth requirement. No filler, front-loaded main action, every sentence earns its place.
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 single-parameter tool with an output schema, the description covers purpose, usage context, and auth prerequisite. It lacks explicit differentiation from sibling profile tools (e.g., get_user_profile), which would improve completeness, but overall it's adequately self-contained.
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 is fully described in the schema with format examples, so baseline is 3. The description adds value beyond the schema by mentioning the required SHIPPOST_API_KEY configuration, giving context about the environment needed to run the tool.
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 identifies the action ('Analyze a Twitter account') and specifies the scope of analysis: 'who they are, what they post about, engagement patterns.' This distinguishes it from raw-data tools like get_user_profile or get_timeline, though it doesn't explicitly name alternatives, so it stops short of a full 5.
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 explicit context: 'Useful for deciding whether to engage with someone or understanding their audience.' This gives a clear reason to invoke the tool but does not mention exclusions or alternatives, so it's a solid 4 rather than a 5.
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?
With no annotations, the description carries full burden. It discloses the non-posting behavior and the API key prerequisite, which are key behavioral traits. However, it does not explain what happens to the draft (e.g., if it is saved, returned only, or if there are rate limits). Since it is a mute operation with no side effects mentioned, this is a moderate disclosure.
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 concise sentences: purpose, non-posting clarification, and API key requirement. Every sentence adds value and is front-loaded. No unnecessary detail or repetition.
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 simple tool with 2 parameters and an output schema, this description is mostly complete. It covers the main purpose, the critical non-posting behavior, and the prerequisite. It does not explicitly contrast with draft_reply/draft_thread, but given the name and context, it is sufficient. The return value is hinted as a draft, and the output schema likely handles details.
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 100%, so the description's contribution is minimal. It does not add meaning beyond what the schema already defines for 'topic' and 'style'. The description's mention of 'original tweet' and 'in your voice' relates to behavior rather than specific parameter semantics. Thus, a 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 it drafts an original tweet using AI, with a specific verb ('draft') and resource ('tweet'). It distinguishes itself from post_tweet by explicitly noting it does not post automatically, and the phrase 'in your voice' adds a unique characteristic. This separates it from sibling drafting tools like draft_reply and draft_thread.
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 provides explicit when-not-to-use guidance by stating 'Use post_tweet() to post' and clarifies this tool only produces a draft. It also warns about the API key requirement. However, it does not compare with draft_reply or draft_thread, which could be relevant alternatives for reply or thread 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?
With no annotations provided, the description carries the burden of explaining behavior. It discloses that the tool analyzes a tweet, matches the user's writing style, returns a draft only, never posts automatically, and requires a ShipPost API key. This is solid transparency, though rate limits and error behavior are not mentioned.
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, front-loaded, and avoids unnecessary length. There is minor redundancy between 'in your voice using AI' and 'matches your writing style,' but the API key requirement and draft-not-post warning are useful and earned.
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 low complexity, full schema coverage, and presence of an output schema, the description is largely complete. It covers purpose, key behavior (draft-only), and authentication. Slightly more context about how it relates to draft_tweet/draft_thread would make it fully 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 100%, so the schema already explains tweet_id, tweet_text, and tweet_author. The description adds no additional parameter-level detail, which is acceptable because the schema does the heavy lifting; baseline 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 uses a specific verb+resource pair ('Draft a reply to a tweet') and clarifies the AI voice/style behavior. It distinguishes itself from reply_to_tweet by explicitly noting this returns a draft and does not post, and from tweet/thread drafting tools by focusing on replies.
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 usage context: use this to generate a draft reply, not to post it. It explicitly says 'Use reply_to_tweet() to post,' which is a named alternative. However, it does not fully explain when to choose this over other drafting tools like draft_tweet or draft_thread.
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?
With no annotations, the description conveys that this is a read operation returning tweets where other users @mention the authenticated user. It does not describe pagination or rate-limit behavior, but the output schema and max_results parameter cover the essential invocation 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 the purpose front-loaded. Every sentence adds meaningful 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?
This is a simple one-parameter read tool with an output schema, and the description sufficiently clarifies the scope ('recent', 'other users', 'authenticated user'). No critical context is missing for selection or invocation.
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%, and max_results is fully documented in the input schema. The tool description adds no additional parameter semantics beyond what the schema already provides.
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 a specific verb ('Get') and a unique resource ('tweets that mention me'), clearly scoped to @mentions of the authenticated user. This differentiates it from siblings like get_timeline and search_tweets.
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 when needing the authenticated user's mentions, but it does not explicitly state when to use this tool versus alternatives such as get_timeline or search_tweets. No exclusion criteria or alternative tool names 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?
No annotations are provided, so the description carries the full transparency burden. It discloses that the tool 'Uses AI to analyze each tweet,' lists the three scoring criteria, describes the output as scored tweets with suggested reply angles, and notes the required SHIPPOST_API_KEY. It doesn't mention rate limits or side effects, but no mutating behavior is 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?
The description is well-structured and front-loaded: a one-sentence summary, a concise bullet list of scoring criteria, an output statement, and an auth note. Every section earns its place with no redundant filler.
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 fully described optional parameters, the description covers the essential ground: purpose, behavior, input context, output shape, and authentication. It could be more complete with an explicit 'does not post or like anything' note, but the current level is sufficient for a discovery 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 already fully documents both parameters (niche and max_results) with clear descriptions and defaults, so the baseline is 3. The description adds little parameter-specific detail beyond tying 'niche' to the relevance scoring criterion, which is helpful but not necessary.
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 verb+resource: 'Scan my timeline and find the best tweets to reply to, scored by relevance.' This clearly distinguishes it from sibling tools like get_timeline (raw timeline retrieval) or reply_to_tweet (posting a reply), positioning it as an AI-scored opportunity finder.
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 usage context is clear: use this when you want AI-scored reply opportunities from your timeline, not when you need raw timeline data or immediate posting actions. It doesn't explicitly name alternatives or exclusions, but the description's task framing makes the intended use case unambiguous.
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?
No annotations are provided, so the description carries the full disclosure burden. It meaningfully discloses the 7-day lookback, retweet exclusion, and returned fields (text, author, engagement metrics, URLs). It does not mention pagination or rate limits, but the core behavior is transparent enough for selection.
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 short sentences: the headline purpose comes first, followed by essential scope and result details. There is no filler or redundant phrasing.
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 two simple parameters, a full output schema, and a clear sibling context, the description adequately covers the tool's scope and result content. It could note ordering or pagination, but those are not critical for correctly selecting and invoking this search 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 description coverage is 100%, with query and max_results fully described including examples and default ranges. The tool description adds no parameter-specific detail beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Search recent tweets by keyword or phrase') and further narrows scope with the 7-day window and exclusion of retweets, making it clearly distinct from sibling tools like get_timeline, get_mentions, and get_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 clearly states the search covers the last 7 days of public tweets and excludes retweets, giving useful context for when to use this tool. It does not explicitly name alternative tools for non-search cases, but the keyword-search purpose is unambiguous.
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?
With no annotations provided, the description carries the transparency burden and does it well: it states it does not post, returns drafts for review, and requires a SHIPPOST_API_KEY. It could add minor details like rate limits or cost, but the key side effects and prerequisite are disclosed.
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 compact and front-loaded: first statement defines the action, second states safety/deliverable, third covers prerequisites. Every sentence earns a purpose 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 output schema is present and all three parameters are reliably documented, the description has enough context. It covers what the tool does, that it doesn't post, and the required API key setup, making it complete for a drafting 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 schema already provides 100% coverage with meaningful descriptions for topic, style, and length. The description adds little beyond the schema, so it doesn't meaningfully deepen parameter understanding, though no gaps exist.
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?
Starts with a specific action and resource: 'Draft a tweet thread about a topic in your voice using AI.' It also clarifies the deliverable ('Returns DRAFTS — does not post'), which distinguishes it from posting tools like post_tweet and single-tweet sibling draft_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?
Gives clear workflow guidance: use it to create drafts, not to publish, and explicitly directs the agent to 'use post_tweet() for each' after review. It doesn't explicitly contrast with draft_tweet or draft_reply, but the thread framing and post_tweet pointer make usage context reasonably clear.
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?
No annotations exist, so the description must carry transparency. It indicates 'look up' and lists returned data, implying a read-only operation, but does not explicitly state lack of side effects, rate limits, or error behavior. This is acceptable but not thorough for a tool with no 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 concise sentences, covering the action and the return content without any superfluous words. It is well-structured and easy to parse, making it efficient for an agent.
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 is simple with one parameter and no output schema. The description mentions the key return fields (name, bio, follower/following counts, tweet count), which provides sufficient context. It does not cover edge cases or error conditions, but for a straightforward lookup, this is adequate. Slight deduction for not mentioning potential limitations.
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?
The single parameter 'username' is fully described with format guidance ('without the @ sign') and an example, which adds meaningful context beyond the schema. The description also reinforces the parameter's purpose by referencing 'by their username'. Coverage is 100% and the added detail is valuable.
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: looking up a Twitter user's profile by username. It distinguishes from sibling tools like get_my_profile (which targets the authenticated user) and other retrieval methods, using the specific verb 'look up' and resource 'profile'.
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 (for any user's profile via username) and implicitly contrasts with get_my_profile, but it does not explicitly exclude cases or mention alternatives. It provides clear context but lacks direct guidance on 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.

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:

[![shippost-mcp MCP server](https://glama.ai/mcp/servers/RyanKramer/shippost-mcp/badges/card.svg)](https://glama.ai/mcp/servers/RyanKramer/shippost-mcp)

Score Badge

Copy to your README.md:

[![shippost-mcp MCP server](https://glama.ai/mcp/servers/RyanKramer/shippost-mcp/badges/score.svg)](https://glama.ai/mcp/servers/RyanKramer/shippost-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/RyanKramer/shippost-mcp'

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