20 blogging, brand-voice, copywriting, video and social skill products. 6 of 8 free.
Scored across 8 tools
Each tool targets a distinct function: writing analysis, headline ranking, reading time, social length check, product listing, free skill retrieval, full product retrieval, and paid skill retrieval. There is no overlap, and the descriptions clearly differentiate them.
Tool names use mixed conventions: imperative verbs (get_, list_) for product tools, but descriptive nouns for writing tools (headline_analyzer, reading_time, social_length_check). While not chaotic, the lack of a uniform pattern could cause minor confusion.
With 8 tools covering two related areas (writing analysis and product catalog), the count is well-scoped. Each tool serves a clear purpose without redundancy, fitting the server's 'creator' theme.
The writing tools cover major content needs (draft quality, headlines, reading time, platform limits). The product tools provide complete read-only access to the catalog. A minor gap is the lack of search or filtering, but list_products returns all 20 products, which is adequate.
Analyze a draft for readability, passive voice, cliches, and hedging. FREE.
Also measures sentence variety and keyword density, and produces a prioritized fix list. Typical input {"text": ""} returns {"readability_grade": 9.2, "passive_voice_count": N, "cliches_found": [...], "hedging_words": [...], "sentence_count": N, "avg_words_per_sentence": N, "top_repeated_words": [...], "priority_fixes": ["..."]}.
Use on body prose to find readability and style problems. Not for ranking titles (headline_analyzer) and not for platform limits (social_length_check). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "empty text"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The draft to analyze — at least one full sentence; plain text, any length. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds crucial behavioral details beyond readOnly and idempotent annotations: it never raises protocol errors but returns an error object, and includes sample output structure. This enriches the agent's understanding of expected behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose, example output, usage notes, and error handling, all in a compact form. Every sentence provides value, and key points are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with full schema coverage and an output schema, the description is comprehensive: it covers usage, errors, retry safety, and sample output, leaving little ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter, and the description reiterates the typical input format and adds constraints like 'at least one full sentence' and 'plain text', which go beyond schema essentials.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes drafts for readability, passive voice, cliches, and hedging, and lists additional metrics. It distinguishes itself from siblings by explicitly noting it's not for titles or platform limits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use on body prose and not for ranking titles or checking social length limits, naming alternatives (headline_analyzer, social_length_check). This is clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a product's free gateway skill with its complete instructions. FREE.
Typical input {"slug": "brand-voice"} returns {"slug": "brand-voice", "skill": "", "instructions": ""}.
Returns exactly one skill - the product's free gateway skill - chosen automatically from the slug, with no plan required. Use when the caller wants usable instructions immediately. Not for the product's other skills: those are named and need get_full_skill with a skill_name, which requires a paid plan. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "unknown slug ''. Use list_products."}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug exactly as returned by list_products, e.g. "brand-voice". |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description goes beyond by explaining error behavior: 'never raises a protocol error — it returns an error object' and that after correcting input it is 'always safe to retry'. This adds critical behavioral context above the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: it opens with the core purpose, then provides an input/output example, usage guidelines, differentiation from sibling, error handling, and safety guarantees. Every sentence adds value, and there is no unnecessary repetition or jargon.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with output schema and clear annotations, the description covers everything needed: purpose, usage context, error recovery, and linkage to list_products for valid slugs. It is complete for an agent to select and invoke the tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already states the slug must be exactly as returned by list_products. The description adds a concrete example and clarifies the slug determines which skill is loaded, but does not provide additional semantics beyond what the schema covers. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it loads a product's free gateway skill with complete instructions, specifying it returns exactly one skill chosen automatically from the slug. It explicitly differentiates from get_full_skill, which handles other skills and requires a paid plan. This provides a specific verb-resource scope and clear sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use when the caller wants usable instructions immediately' and explicitly warns 'Not for the product's other skills: those are named and need get_full_skill with a skill_name, which requires a paid plan.' This gives clear when-to-use and when-not-to-use guidance, along with the alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load one product in full: its persona plus every paid skill. PREMIUM (license).
Typical input {"slug": "brand-voice"} returns {"slug": ..., "name": ..., "persona": "", "skills": [{"name": ..., "instructions": ...}, ...], "free_skill": {...}}.
Returns persona plus every skill for one product. Use when the caller wants the whole product. Not for a single skill (get_full_skill) and not for a free look, which list_products and get_free_skill provide with no plan. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "unknown slug ''"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug exactly as returned by list_products, e.g. "brand-voice". |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds error behavior details (never raises protocol error, returns error object with fix guidance) and reaffirms idempotency/read-only nature, providing valuable context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with a front-loaded purpose, example, usage guidance, error handling, and idempotency note. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description compensates with a JSON output example. It covers licensing, error behavior, retry safety, and distinction from sibling tools. Sufficient for a simple 1-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a clear parameter description. The description adds an inline example of typical input, which reinforces parameter usage but doesn't add substantial new meaning beyond the schema. Baseline 3 with slight improvement for contextual example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it loads a full product with persona and all paid skills, using specific verbs and resource. It distinguishes from siblings like get_full_skill and list_products, making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use 'when the caller wants the whole product' and when not—for single skill or free look—naming specific alternative tools (get_full_skill, list_products, get_free_skill). Also mentions license requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load one paid skill's complete instructions from a product. PREMIUM (license).
Typical input {"slug": "brand-voice", "skill_name": "Voice Audit"} returns {"slug": ..., "skill": ..., "instructions": ""}.
Returns one named skill, selected by skill_name. Use when the caller wants one specific paid skill. Not for the free gateway skill, which get_free_skill returns with no plan, and not for every skill at once (get_full_product). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "unknown slug ''"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug exactly as returned by list_products. | |
| skill_name | Yes | Exact skill name as listed in that product's "skills" array from list_products. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant behavioral context beyond annotations: error handling details ('never raises a protocol error — it returns an error object'), retry safety, and idempotency. Annotations already declare readOnlyHint and idempotentHint, and the description reinforces these with practical implications. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured: front-loaded with main purpose, then example, usage guidelines, error handling, and idempotency note. Every sentence adds value with no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, 100% schema coverage, clear annotations, output schema), the description is complete. It covers purpose, usage, error behavior, and safety, leaving no gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters well. The description provides an example but does not add new semantic meaning 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.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool loads one paid skill's complete instructions from a product. It provides a typical input/output example and distinguishes from siblings: get_free_skill for free gateway skill and get_full_product for all skills at once. The verb 'load' is specific and the resource is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use when the caller wants one specific paid skill.' Also lists exclusions: 'Not for the free gateway skill... and not for every skill at once (get_full_product).' This provides clear guidance on tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score and rank up to 20 headlines, best first. FREE.
Scores 0-100 on length, power/emotion words, numbers, structure, and clarity. Typical input {"headlines": ["7 Mistakes New Writers Make", "On Writing"]} returns {"ranked": [{"headline": ..., "score": 85, "notes": ["good length", "contains number"]}, ...]}.
Use when several title options need ranking. Not for email subject lines, which the outbound server's subject_line_scorer judges against deliverability signals, and not for body prose (analyze_writing). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""}. Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| headlines | Yes | List of candidate headlines as plain strings; only the first 20 are scored. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds value by clarifying the error behavior (returns error object, never raises protocol errors), the 20-headline limit, and the scoring dimensions. However, it doesn't mention whether the order of ties is deterministic or any rate limits. Still, with strong annotations, the bar is low, and the added context is helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise at ~6 sentences, with critical info front-loaded (purpose, free, example). The second paragraph adds usage guidelines and error behavior efficiently. Minor structural improvement: the error handling sentence could be a separate paragraph, but overall it's well-organized and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage boundaries, input/output example, error handling, idempotency/read-only safety, and points to relevant siblings. Given the tool's simplicity (1 param, clear schema, rich annotations, output schema present), this is a complete and self-sufficient description that leaves little ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter ('headlines') well, including that only the first 20 are scored. The description reinforces this with an example but adds little new about parameter syntax or constraints beyond what the schema provides. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb ('Score and rank'), names the resource ('headlines'), and clarifies the scope ('up to 20 headlines, best first'). The example input/output reinforces the purpose, and it clearly distinguishes from siblings like analyze_writing which handles body prose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use ('several title options need ranking') and provides clear exclusion criteria: 'Not for email subject lines' (pointing to subject_line_scorer) and 'not for body prose' (pointing to analyze_writing). It also discusses error handling and retry safety, giving the agent full context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every product in the Creator Studio line with its included skills. FREE.
Takes no arguments. Returns a list of 20 product objects, each {"slug": "brand-voice", "name": ..., "tagline": ..., "skills": ["Skill A", ...], "free_skill": "Gateway Skill Name"}. Use the returned slug values with get_free_skill, get_full_product, or get_full_skill.
Returns metadata only - no persona text and no skill instructions. Use when the caller wants to see what this server covers. Not for keyword search across the whole 138-product catalog, which the catalog server's search_catalog does, and not for instructions the caller can act on (get_free_skill). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""}. Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by disclosing that the tool never raises protocol errors on invalid input, instead returning an error object with fix instructions. It also states the return format precisely (list of 20 product objects with slug, name, tagline, skills, free_skill) and confirms read-only idempotent behavior, reinforcing the readOnlyHint and idempotentHint annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the essential purpose in the first sentence, followed by structured details on arguments, return format, usage guidance, error behavior, and safety. Every sentence adds meaningful information without redundancy or fluff. At 8 sentences, it is appropriately sized for the tool's complexity and sibling context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters, an output schema, and annotations that already cover read-only/idempotent behavior, the description adds complete context: return structure, error handling, usage scenarios, and sibling differentiation. There are no gaps—the agent has everything needed to decide when and how to call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description explicitly states 'Takes no arguments,' which adds clarity beyond the empty schema. While there's nothing to add about individual parameters, the description compensates by explaining the return format and usage of slug values, which is actionable context for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), identifies the exact resource ('every product in the Creator Studio line'), and clarifies the scope ('with its included skills. FREE.'). It also explicitly distinguishes itself from siblings by stating what the tool does NOT return (no persona text, no instructions) and by naming sibling tools for further actions (get_free_skill, get_full_product, get_full_skill). This makes the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent exactly when to use this tool ('when the caller wants to see what this server covers') and when not to ('Not for keyword search...use catalog server's search_catalog'). It also clarifies what the tool is not suited for ('not for instructions the caller can act on') and suggests alternatives (get_free_skill). This is explicit, clear guidance with exclusions and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate reading and speaking time plus basic content stats. FREE.
Typical input {"text": ""} returns {"words": 1200, "reading_minutes": 5.2, "speaking_minutes": 8.6, "paragraphs": 14, "fit": "newsletter/blog"}.
Use when length and pacing are the question. Not for writing quality or grade level (analyze_writing). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""}. Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| wpm | No | Silent reading speed in words per minute; values below 60 are treated as 60. Default 230. | |
| text | Yes | The content to measure, plain text. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive. The description adds valuable context: it never raises protocol errors but returns an error object with fix guidance, and reaffirms read-only and idempotent behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: opening purpose, example, usage guidance, error handling. No extraneous text. Slightly longer due to example, but all content earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with full schema coverage, output schema, and annotations, the description covers all necessary aspects: purpose, when to use, error handling, and behavior. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions. The description does not add semantic meaning beyond the schema; it provides an example of typical input and output but does not elaborate on parameters themselves. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates reading and speaking time plus basic content stats. It explicitly distinguishes itself from the sibling tool 'analyze_writing' by noting it is not for writing quality or grade level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use (when length and pacing are the question) and when not to use (not for writing quality/grade level), naming the alternative 'analyze_writing'. This provides clear decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
analyze_writingget_free_skillget_full_productget_full_skillheadline_analyzerlist_productsreading_timesocial_length_check7 outreach, sequencing, call-coaching and CRM-hygiene skill products. 6 of 8 free.
20 inbox, calendar, travel, meals and family-logistics skill products. 7 of 9 free.
30 finance, bookkeeping, legal-ops and SMB operations skill products. 6 of 8 tools free.
7 research navigation, thesis, note-taking and citation skill products. 6 of 8 free.
Add one secure layer between your agents and this server.
social_length_checkSocial Length CheckARead-onlyIdempotent Inspect
Check a post against every major platform's length limit at once. FREE.
Covers X, LinkedIn posts and headlines, Instagram captions, Threads, YouTube titles, and meta descriptions. Typical input {"text": ""} returns {"chars": N, "platforms": {"x_post": {"limit": 280, "fits": true, "over_by": 0}, ...}}.
Use before posting, to catch truncation. Not for readability (analyze_writing) and not for reading duration (reading_time). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""}. Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
Output Schema
No output parameters
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds detailed behavioral traits: the tool never raises protocol errors on invalid input, returns a structured error object, and is always safe to retry. This provides valuable context not present in annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose, and every sentence adds meaningful information (usage, example, error behavior, safety). No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, read-only semantics, and a predictable output (example given), the description covers purpose, usage, error handling, and retry safety. It is fully sufficient for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the 'text' parameter. The description adds example input format but no additional meaning beyond what the schema already provides. The baseline of 3 is appropriate since the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks a post against every major platform's length limit at once, listing specific platforms (X, LinkedIn, Instagram, etc.). It distinguishes itself from sibling tools like analyze_writing and reading_time by explicitly noting what it does not cover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use before posting, to catch truncation. Not for readability (analyze_writing) and not for reading duration (reading_time).' It also explains error handling and that retries are safe, giving the agent clear context for when and when not to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.