Pipepost
Server Quality Checklist
Latest release: v0.9.0
- Disambiguation5/5
Each tool has a clearly distinct purpose. Even overlapping tools like generate_social_posts and repurpose are differentiated by their specific outputs and use cases. All platform-specific posting tools target different social networks, and management tools (drafts, publishing, SEO) are neatly separated.
Naming Consistency5/5Tool names follow a consistent verb_noun pattern (e.g., activate, bluesky_post, check_links, generate_social_posts, save_draft). The naming is descriptive and predictable, making it easy for an agent to infer functionality.
Tool Count4/5With 28 tools, the server is comprehensive but slightly heavy. However, each tool serves a specific need within the content marketing domain, and the count is justified by the breadth of platforms and features covered. It is not excessive given the scope.
Completeness3/5The tool surface covers major workflows (drafting, publishing to multiple platforms, SEO, analytics, social posts) but has notable gaps like no edit/update for published posts, no scheduling, and no comment management. Some features require external tools or manual steps.
Average 4.4/5 across 28 of 28 tools scored. Lowest: 3.8/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
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto 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?
Without annotations, the description partially fills the gap by stating it lists notifications, returns a specific object, and mentions common errors and fallback behavior. However, it does not disclose rate limits, side effects, or confirm read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using three sentences to cover purpose, defaults, FREE status, required configuration, return format, and errors. It is front-loaded with the main action and avoids unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides a good level of completeness: it states the return structure, common errors, and fallback. It lacks ordering information but covers the essential context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have descriptions in the schema (100% coverage), so baseline is 3. The description adds the default reasons ('mention','reply') and valid values for 'reasons', but does not provide additional meaning for 'limit' or 'cursor' beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists notifications (mentions/replies) for the configured Bluesky account, with optional inclusion of reposts/likes/follows. It distinguishes itself from siblings like bluesky_post, bluesky_reply, and bluesky_search by focusing on the user's own notifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking notifications but does not explicitly provide when-to-use or when-not-to-use guidance relative to sibling tools. It mentions 'FREE' and required credentials, but no alternatives are suggested.
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?
Discloses 'FREE' status, return format, and error condition. No annotations provided, so description carries burden; lacks mention of authorization or rate limits but adequate for simple read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded verb 'Retrieve', zero wasted words. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for simple tool: specifies action, return shape, error. Minor gap: could mention relation to 'save_draft' or 'list_drafts'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with description. Description adds no new parameter semantics beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves draft content by ID. Distinguishes from siblings like 'list_drafts' (list all) and 'delete_draft' (delete).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use when you have a draft ID. Mentions common error (ID not found) but lacks explicit when-not or alternatives like using 'list_drafts' to get IDs.
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 provided, so description must carry behavioral info. It discloses local execution, credit cost, and common error (PAYMENT_REQUIRED). However, it does not specify behavior for missing keyword or very long content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first sentence captures core function and constraints; second adds cost, return structure, and common error. No wasted words, front-loaded with essential info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description reasonably covers purpose, parameters, cost, error, and return format. Could slightly improve by mentioning how to handle long content, but sufficiently complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds no additional parameter semantics beyond what the schema provides, meeting baseline expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates SEO-optimized meta tags (title, description, Open Graph) from article content with specific character limits, and distinct from siblings like seo_schema or seo_score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions no external calls, runs locally, and cost of 1 credit, but does not explicitly compare to sibling tools like seo_schema (for schema markup) or seo_score (for scoring). Use context is implied but not explicit.
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 provided, so description carries full burden. It discloses cost (1 credit), output format, and common errors (VALIDATION_ERROR, PAYMENT_REQUIRED). Could be more explicit about side effects (e.g., read-only nature), but effectively communicates behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with three sentences: purpose, output format, and common errors. No redundant information, front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema, the description covers input, output structure, errors, and cost. Could expand on data parameter constraints per type, but sufficient for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds error context (invalid type/content) but does not significantly enhance parameter semantics beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates JSON-LD structured data for specific Schema.org types (Article, FAQPage, HowTo), with output ready for script tags. It distinguishes from siblings like seo_meta and seo_score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions cost and output but does not provide explicit guidance on when to use this tool versus alternatives (e.g., seo_meta, seo_score). Usage is implied but no exclusions or comparative context.
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 carries the full burden. It discloses that the tool is free, requires an access key, has rate limits, and returns specific data. It also mentions common errors. It does not explicitly state that it is read-only, but the context implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two sentences plus a compact representation of return format and errors. It is front-loaded with the core purpose. The return format could be more formal, but it is still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple external API search tool with three parameters, the description covers setup, rate limits, common errors, and return format. It could include pagination or ordering details, but it is largely complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the description adds no new information beyond the schema. It repeats the high-level purpose but does not provide additional semantic value for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search Unsplash for cover images,' specifying the external service, action, and resource. It distinguishes itself from sibling tools that perform different actions like 'get_draft' or 'publish'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by mentioning the free nature, required setup of an access key, and rate limits. It also lists common errors. However, it does not explicitly guide when to use this tool versus alternatives like other social media posting tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses key behaviors: irreversible deletion, return format, common errors. Could add auth or scope info, but sufficient for simple operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with action. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete with 1 param and no output schema, covers action, irreversibility, return shape, and common error. Fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with description 'Draft ID to delete'. Description adds minimal extra (e.g., 'by id'), not enhancing meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Permanently delete a saved draft by id.' Specific verb and resource, distinguishes from siblings like save_draft, get_draft, list_drafts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage from description, but no explicit when-to-use or when-not-to-use guidance. Does not mention alternatives or context beyond the action.
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 provided, so description carries full burden. Discloses it's a read operation (FREE), requires credentials, return shape, and common errors. Lacks pagination or rate limit details, but acceptable for a listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with main action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides return format and common errors. Missing pagination info but otherwise complete for a simple listing tool with 3 params and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%) with only platform described. Description does not elaborate on status or limit beyond what schema shows. Does not compensate for missing param descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List your published and draft posts on a configured platform' with specific verb (List) and resource (posts), and enumerates supported platforms. It distinguishes from siblings like list_drafts which is a subset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: requires configured platform credentials, FREE, common errors. Does not explicitly exclude alternatives or state when not to use, but the context implies it's for listing posts on configured platforms.
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 full burden. It discloses credit cost, output preservation of URLs and character limits, and error conditions. However, it does not mention idempotency, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph that front-loads the main purpose and covers cost, output format, and errors concisely without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description is comprehensive: it explains the transformation, credit cost, output shape with TypeScript-like types, and common error. This is sufficient for an agent to understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% parameter description coverage, so the description adds marginal value beyond the schema. The description reiterates some context (credit cost, output shape) but does not clarify parameter specifics further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Transform' and resource 'full blog post' into specific platform-native content for six named platforms. This distinguishes it from sibling tools like 'generate_social_posts' or 'cross_publish'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions credit cost and common error but does not explicitly state when to use this tool versus alternatives. It implies usage for repurposing a blog post to platform-native formats, but lacks exclusions or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It covers limits (300 graphemes), URL handling, return format (uri, cid, posts array), and common errors. It doesn't detail rate limits or visibility, but these are standard for posting tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three sentences covering purpose, prerequisites, behavior, and errors. It front-loads the primary function and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two params, no output schema, no annotations), the description adequately covers purpose, prerequisites, limits, error types, and return format. Minor gaps include lack of detail on response handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description repeats the mutual exclusivity and character limits already present in the schema. It adds no new semantic information beyond what the input schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool posts directly to Bluesky as a single post or reply-chained thread. It uses specific verbs and resources, distinguishing it from sibling tools like bluesky_mentions or bluesky_reply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context including prerequisites (configured handle and app password), grapheme limits, and URL auto-linkification. However, it doesn't explicitly exclude scenarios or mention alternative tools for replying or reading, leaving some ambiguity.
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 carries the full disclosure burden. It transparently explains the API submission behavior, return format, and error types. It also states it's free and uses a shared key. However, it does not mention rate limits or potential side effects on the user's account, which would enhance completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three sentences covering purpose, cost/credentials, and return/errors. It is front-loaded with the primary action. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple API submission tool, the description sufficiently covers the purpose, supported engines, cost, return format, and common errors. It lacks details on prerequisites (e.g., URL validity or domain ownership) and daily limits, but overall it is adequately complete given the lack of output schema and simple parameter schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (url and urls) with clear descriptions and constraints. The description adds context about submitting 'one or more URLs' but does not provide additional semantics beyond the schema. Given 100% schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Submit one or more URLs to the IndexNow API for instant search-engine indexing' and specifies the target search engines (Bing, Yandex, Naver, Seznam) and excludes Google. This distinguishes it from sibling tools which focus on analytics, social posting, or content management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use (for submitting URLs to indexing across specific engines) and notes that no platform credentials are required and it's free. It also lists common errors, aiding proper usage. However, it does not explicitly contrast with sibling tools or mention when not to use, but the distinct purpose makes it clear enough.
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 carries full burden. It discloses that the tool validates the key against the license server, adds credits to the local balance, and returns a structured object with fields like activated, plan, credits_added, total_credits. It also mentions common error types. It does not discuss idempotency or behavior if the key is already activated, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: action, validation and credit addition, then return value and errors. It is front-loaded 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.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is complete: it explains the action, provides the return shape, and lists common errors. No important aspect is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is fully covered (100%) with a clear description for license_key: 'Your Pipepost license key from Lemon Squeezy'. The description adds that the key is from pipepost.dev and validates against the license server, but this adds minimal value beyond the schema description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool activates a Pipepost credit-pack license key from pipepost.dev, with a specific verb+resource. It is distinct from sibling tools which include analytics, social media posting, and content management; none duplicate this function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use (for activating a purchased license key), notes it is FREE, and lists common errors (VALIDATION_ERROR, NETWORK_ERROR) to help decide if the tool is appropriate. However, it does not explicitly state when not to use or mention alternatives, but given no sibling tool serves the same purpose, this is minor.
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?
No annotations are provided, so the description carries the full burden. It explicitly states 'No external calls' and describes auto-extraction of description, reading time, slug, and tags. It also specifies the return format and common errors (VALIDATION_ERROR for unknown format). This covers key behavioral aspects thoroughly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that packs important information efficiently: purpose, formats, features, return, and common errors. It is front-loaded and every sentence adds value. However, it could be slightly more structured (e.g., bullet points) for clarity, but it remains effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters (3 required) and no output schema, the description compensates by explaining the return value and extracted fields. It mentions common errors. The schema covers parameter meanings. The description is sufficient for an AI agent to use the tool, though edge cases (e.g., empty content) are not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context about auto-extraction from content but does not add substantial new meaning beyond what the schema already provides for each parameter. The explanation of auto-extraction is already implied by the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates frontmatter for specific SSGs and platforms, listing supported formats (hugo, jekyll, etc.). It uses a specific verb ('Generate') and resource ('frontmatter'), and the scope is clearly defined. The tool is distinct from siblings like publish or save_draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it is FREE and makes no external calls, which helps with usage decisions. It implies this is a utility step before publishing, but does not explicitly state when not to use it or alternatives. However, the context of sibling tools (publish, save_draft, etc.) makes the use case clear.
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; description discloses read-only nature, file path, and specifies return format with 'No errors.' Adequate for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus one line for return type. No wasted words; all information is relevant and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description accurately defines return structure inline. Covers location, fields, and error behavior comprehensively for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage for the only parameter 'status' with enum and description. Description adds no extra detail, meeting baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List every saved local draft' with specific fields, distinguishing it from siblings like get_draft and delete_draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
States it is FREE and reads from a local path, implying no side effects. Does not explicitly contrast with alternatives, but purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: it writes to a local file, never transmits data, replaces existing credentials, returns a structured response with validation status, and mentions common errors. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 3 sentences and no fluff, but it could be more structured (e.g., bullets for platforms). The front-loading of purpose is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return format and a common error. It does not cover all edge cases (e.g., invalid credentials not just missing) or rate limits, but it's sufficient for a simple configuration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the two parameters. The description adds that credentials are 'API credentials as key-value pairs' and mentions missing fields cause VALIDATION_ERROR, but it incompletely lists platforms (missing x, linkedin, reddit, bluesky, mastodon) compared to the schema, which could mislead. Baseline 3, adjusted down slightly for the omission.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures and persists platform credentials to a specific file, using the verb 'Configure and persist' and specifying the resource '~/.pipepost/config.json'. It distinguishes itself from sibling tools like 'publish' or 'activate' by being the only credential setup 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists supported platforms and notes that existing credentials are replaced, giving context for when to use. It does not explicitly state when not to use or mention alternatives, but the sibling tool names imply it's for initial setup.
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?
No annotations, so description carries full burden. Fully discloses OAuth 1.0a signing, free API cap, return format, and error types. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise paragraph with distinct info chunks. Some technical detail (OAuth HMAC-SHA1) is extra but not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description specifies return shape with optional thread array. Covers common errors, setup requirement, and rate limits. Complete for a single social posting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline 3. Description adds minor context (grapheme vs char, v2 API) but does not significantly extend beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it posts directly to X (Twitter) as a single tweet or reply-chained thread via X v2 API. It specifies max length (280 graphemes). Distinguishes from siblings like bluesky_post, linkedin_post by platform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions required credentials, rate limit (17 tweets/24h), and common errors. Does not explicitly contrast with alternatives like cross_publish, but sibling names make platform clear.
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 carries full burden. It discloses credential requirements, grapheme limit, automatic computation of root/parent references, return format, and common errors. Lacks information on rate limits or idempotency, but covers key behaviors adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Five concise sentences, front-loaded with primary action, no redundant parts. Efficiently conveys all necessary information without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description returns format and errors well. It lacks explicit mention of mutual exclusivity between text and thread (though schema covers it). Overall sufficient for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, yet description adds meaningful context: explains automatic computation of AT Protocol references, reinforces character limit, and clarifies the thread chain behavior. This goes beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Reply to a Bluesky post as a single reply or a chained thread,' specifying both the action and the resource. It effectively distinguishes from sibling tools like bluesky_post (new post) and bluesky_thread (view 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions requirements (credentials, grapheme limit) and common errors, guiding proper use. It implicitly differentiates from posting new content but could explicitly state when not to use it (e.g., for creating original posts). Still, it provides clear context for typical usage.
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?
Without annotations, the description fully discloses behavior: HEAD then GET fallback, reporting broken/redirected/timeout links, concurrency limits, per-URL timeout, and error handling (malformed markdown returns empty results). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences plus a clear output format list. It front-loads the purpose and key behavioral traits, making it efficient for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all relevant aspects: input, method, limits, output structure, and error cases. Given no output schema, it provides the return format explicitly. It is complete for a link validation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'content' is fully described in the schema. The tool description adds context about expected markdown input and outputs but does not add meaning beyond the schema for the parameter itself. Baseline 3 for 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates URLs in markdown documents using HEAD then GET fallback. It specifies the resource (URLs in markdown) and verb (validate), and implicitly distinguishes from siblings as no other tool does link checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: it's free, concurrency-limited to 10 requests, timeout 8s, and common errors like malformed markdown. It doesn't explicitly contrast with alternatives, but no sibling does similar work, so it's adequate.
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 burden. It discloses the cost model (free basic, paid full) and the return format. It does not explicitly state read-only, but the nature of an audit implies no destructive side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two paragraphs with no fluff. Every sentence adds value—purpose, checks, cost, return format, common errors. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's functionality, cost, return format, and common error. Without an output schema, it adequately describes the return object. It could mention handling of invalid or empty content, but overall it is complete for an audit tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions, but the tool description adds significant value by explaining what 'full' does (readability, structure, tags, heading hierarchy) and what basic provides (counts, summary). It also details the return object structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'audit' and the resource 'markdown article', listing specific checks (heading hierarchy, paragraph length, etc.). It differentiates from sibling tools by focusing on content quality rather than SEO or publishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use basic vs full audit based on credit cost and mentions a common error (PAYMENT_REQUIRED). It does not explicitly compare to sibling tools, but the context of pre-publish quality is clear.
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, description discloses character limit (500), return format, and common errors (VALIDATION_ERROR, PLATFORM_ERROR). Adds behavioral context beyond basic post action, though could mention rate limits or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences; each conveys essential info (action, credentials, limits, return, errors). No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, return format is described. Errors, credentials, and behavior are covered. All parameters are explained in schema or description. Sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but description adds value by explaining mutual exclusivity of 'text' and 'thread', and that 'max_length' overrides default limit. Could clarify that thread creates replies referencing previous posts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Describes specific verb 'post' and resource 'Mastodon instance', with distinction between single status and threaded series. Clearly differentiates from sibling tools targeting other platforms like Bluesky or X.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions required credentials (instance_url, access_token) and scope, and notes that the tool is free. Implicitly distinguishes from other platform-specific tools via platform name, but no explicit when-not-to-use or alternative recommendations.
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 provided, so description carries full burden. It states the tool is machine-local and never transmitted, and lists common errors with types. It also specifies the return structure. However, it does not mention authentication or rate limits, though not critical for a local tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise at 5 sentences, each providing distinct value: purpose, free cost, usage context, return structure, and common errors. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description includes return structure and common errors. It references sibling tools for later publishing. All 5 parameters are documented in the schema, and the description adds meaningful context, making it complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds value by explaining the context of platforms as targeting later publishing, and notes the tool is free. This goes beyond repeating schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool saves markdown content as a local draft in a specific path, distinguishing it from sibling tools like publish and cross_publish. The verb 'save' and resource 'local draft' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description indicates when to use the tool (save locally for later publishing) and mentions alternatives (publish, cross_publish). It lacks explicit 'when not to use' but provides sufficient context.
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 provided, so the description carries the burden. It declares 'No errors,' indicating safe execution, and lists the return structure. This adequately discloses behavioral traits for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence for purpose, two brief statements for usage, and a clear return struct. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully specifies the return fields ({ version, credits, platforms, plan }). Combined with the clear purpose and 'No errors' statement, it provides complete context for a status tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage (empty schema), the description adds value by explicitly stating 'No arguments.' This confirms the lack of parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Show' and specifies the exact resources (configured platforms, credit balance, reset date, license plan), making the tool's purpose immediately clear. It distinguishes from sibling tools that perform actions like posting or publishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'FREE. No arguments,' implying it can be called anytime with no prerequisites. While it does not explicitly mention when not to use it or alternatives, the context is clear for a status check tool.
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 fully carries the behavioral disclosure burden. It mentions the tool is free, requires no credentials for public threads, describes the return format, and lists common errors (VALIDATION_ERROR, PLATFORM_ERROR). It does not mention rate limits or side effects, but for a read-only tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences front-load purpose, usage guideline, output/errors. Every sentence adds unique value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description specifies the return shape ({ thread: { post, parent?, replies?: thread[] } }) and mentions common errors. It covers all essential context for a read-only conversation fetch tool given the sibling list and annotations absence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% parameter description coverage (uri, depth, parent_height). The description adds value by stating defaults (depth default 6, parent_height default 80) beyond the schema's min/max constraints, making parameter usage clearer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function with specific verb 'Fetch' and resource 'full conversation around a Bluesky post', and distinguishes it from siblings like bluesky_reply by stating it should be used before replying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this before bluesky_reply to understand the conversation', giving clear context for when to use. Also notes 'FREE' and 'No credentials required' for public threads. Missing explicit when-not-to-use statements, but the direction is strong.
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?
With no annotations, the description fully discloses behavioral traits: basic scoring is free, full analysis costs 1 credit, output includes optional fields (issues, suggestions), and common errors (VALIDATION_ERROR, PAYMENT_REQUIRED). This exceeds disclosure needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two main sentences plus return and error notes. It front-loads the core purpose. While not using bullet points, it remains clear and efficient without redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers all essential aspects: tool purpose, parameters, free vs. paid tiers, return structure (with optional fields), and error conditions. It is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context by linking the keyword parameter to scoring criteria (keyword density) and mentioning the 'content' parameter in error handling. This adds meaningful value beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes markdown content for SEO quality, returning a 0-100 score with grade. It distinguishes basic (free) and full (paid) analysis, and differentiates from siblings like seo_meta (metadata) and seo_schema (schema markup) through the focus on content quality scoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (for SEO analysis of markdown) and explains the two tiers (free vs. credit-costing). It does not explicitly compare to sibling tools or state when not to use, but the error conditions (e.g., missing content, insufficient credits) guide proper usage.
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?
Given no annotations, description fully covers behavior: requires credentials, free, platform limitations, return format, and common errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured with two main sentences plus error notes. Front-loaded purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description provides comprehensive return structure and error scenarios. Complete for a 2-parameter fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining 'omit for all configured platforms' for platform parameter and default/behavior for limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it fetches post views, reactions, and comments from multiple CMS platforms and aggregates totals. Distinguishes from siblings which are social media or 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on required credentials, free usage, platform limitations, and common errors. Lacks explicit when-to-use vs alternatives but still helpful.
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?
Without annotations, the description fully discloses the return format (posts array with fields), the need for authentication, the fact it's free, and common error types. This provides complete behavioral transparency for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: purpose, auth requirement, return format and errors. It is front-loaded with the main action and avoids any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and no output schema, the description covers the return structure, auth requirements, and common errors. It explains the key aspects needed for the agent to invoke the tool correctly, including the default for sort and the need for no hashtag prefix on tags (though tag detail is in schema). It feels complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (89%), so baseline is 3. The description adds value by clarifying the query format (Lucene-style, with examples) and explaining the sort enum meanings ('latest' for freshness, 'top' for engagement). This goes beyond the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches public Bluesky posts with filters by keyword, author, mentions, tag, or language, using the specific endpoint. This differentiates it from sibling tools like bluesky_mentions (which may focus on mentions only) and bluesky_post (which creates posts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that authentication is now required (handle + app password) and lists common errors (VALIDATION_ERROR, PLATFORM_ERROR), guiding the user on prerequisites and error handling. However, it does not explicitly contrast this tool with alternatives like bluesky_mentions for mention-specific searches, leaving some ambiguity for the AI agent.
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?
No annotations provided, so the description carries full burden. It covers canonical URL wiring, per-platform failure behavior, common errors, and credit cost. This is comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but efficiently packs information. It could be structured into bullets for readability, but it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters and no output schema, the description provides return value structure, common errors, and per-platform result handling. It covers all necessary context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions. The description adds value by explaining canonical URL wiring, platform-specific notes (e.g., subtitle for Substack, series for Dev.to/Hashnode), and primary_platform behavior, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Publish one article to multiple CMS platforms in a single call', which is a specific verb+resource. It distinguishes from sibling tools like 'publish' (likely single platform) and platform-specific tools (bluesky_post, linkedin_post, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions credit cost, credential requirement, and error handling. It doesn't explicitly state when to use this vs alternative tools like 'publish' or 'repurpose', but the context of multi-platform publishing is clear.
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 provided; description carries full burden. Discloses cost, credential requirements, return structure, and common error. Slightly vague on whether it modifies any state, but generation is inherently read-like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with platforms and cost, then returns, then errors. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers inputs, outputs, error cases, cost, and alternatives. No output schema, but return structure is described clearly. Complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, but description adds context: explains that content is preferred over title/summary, and platforms are listed. Clarifies usage of alternative fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Describes generating platform-optimized social copy from an article, lists specific platforms (twitter, linkedin, reddit, bluesky) with formats. Clearly distinguishes from posting tools by naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: to generate copy (not post), and names alternatives for posting (bluesky_post, linkedin_post, etc.). Also notes cost (1 credit per call) and that no platform credentials are required.
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?
With no annotations provided, the description fully discloses behavioral traits: it's free, requires a specific access token and scope, auto-resolves and caches the person URN, and describes the return format along with common error conditions. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with three short sentences, each providing essential information. It front-loads the core action and uses clear punctuation, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and no output schema, the description is fully complete. It covers the action, requirements, limitations, return format, and errors, leaving no significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for the 'text' parameter. The description adds meaningful context beyond the schema by specifying the 3000-character limit and the threading limitation, adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool posts directly to LinkedIn as a single feed post, with a max length of 3000 chars. It distinguishes itself from potential siblings that might do threading by explicitly noting LinkedIn has no public threading API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions that only single posts are supported due to LinkedIn's lack of threading API, and lists common errors. This provides clear guidance on when to use this tool and what to expect.
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?
No annotations provided, so description carries full burden. Discloses Substack's reverse-engineered cookie auth, return structure, common error scenarios, and costs. For a mutation tool, this is exceptional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph packs maximum information: platform list, cost, prerequisites, supported features, auth detail, return format, and common errors. No superfluous content; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema or annotations, description covers all necessary context: purpose, usage rules, parameter nuances, error handling, and return value. Agent has sufficient information to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 9 parameters are described in schema (100% coverage). Description adds value by noting platform-specific behavior (e.g., 'subtitle' only for Substack, 'series' only for Dev.to/Hashnode) and optionality, exceeding schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states action (publish), resource (markdown article), and target (one of six specific CMS platforms). Distinguishes from sibling tools like cross_publish and save_draft by specifying single-platform publishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions prerequisite (platform credentials via 'setup' tool), cost (1 credit per call), and lists common error types with codes. Guides agent on when to use and what to check before calling.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/MendleM/pipepost'
If you have feedback or need assistance with the MCP directory API, please join our Discord server