20 blogging, brand-voice, copywriting, video and social skill products. 6 of 8 free.
Scored across 8 tools
Most tools target clearly distinct actions, and descriptions explicitly cross-reference near-neighbours (analyze_writing vs headline_analyzer vs social_length_check). The only mild overlap is the trio get_free_skill / get_full_skill / get_full_product, which share a slug-based shape and could be momentarily confused, though each description states its scope and exclusions.
Three tools follow verb_noun (get_free_skill, get_full_skill, get_full_product, list_products, analyze_writing), but headline_analyzer, reading_time, and social_length_check use bare noun_noun_agent style with no verb. The mix is readable but not a single predictable convention.
Eight tools is well within the ideal band and each earns its place: discovery, three tiers of product/skill loading, and four distinct free content-analysis utilities. No redundant or trivial tools.
The surface covers the read-only lifecycle end to end: list products, then fetch free skill, one paid skill, or the full product, plus a coherent set of writing/social analysis helpers. Minor gaps are keyword search within the 20-product line (explicitly punted to a sibling catalog server) and any way to enumerate skill names other than list_products metadata.
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?
Goes well beyond the annotations by disclosing the error contract: invalid, missing, or malformed input never raises a protocol error but returns a structured {"error": ...} object, plus a safe-to-retry guarantee. Annotations already cover read-only/idempotent, but the error-handling and retry semantics are new information an agent needs for recovery logic.
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 purpose and routing sentences are front-loaded and tight, but the multi-line JSON return example consumes a large share of the description while an output schema already exists, making it largely redundant. The 'FREE' and retry sentences earn their place; the return-field blob does not.
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, read-only analysis tool with full schema coverage, an output schema, and annotations, the description covers what remains: scope, exclusions, alternatives, input example, and failure/retry behavior. An agent has everything needed to invoke and recover 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%, so the single 'text' parameter is already fully documented in the schema. The description adds only an example call shape ({"text": "<your draft>"}) and an implicit constraint that input should be body prose. Baseline 3 is appropriate when the schema carries the parameter burden.
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?
States a specific verb and resource ('Analyze a draft') and enumerates the concrete dimensions checked (readability, passive voice, cliches, hedging, sentence variety, keyword density). It also names the sibling tools it is not (headline_analyzer, social_length_check), so an agent can route without opening schemas.
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?
Gives explicit positive scope ('Use on body prose to find readability and style problems') and explicit exclusions with the alternative tool named for each: not for ranking titles (headline_analyzer), not for platform limits (social_length_check). Nothing is left to inference.
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?
Beyond the annotations, it discloses the free/no-plan requirement, the single-skill selection behavior, and a full error contract: no protocol errors, an {"error": ...} object with remediation guidance (e.g. 'unknown slug... Use list_products'), plus retry safety. This is meaningful context an agent could not infer from readOnlyHint/idempotentHint 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?
Front-loaded with purpose, free status, and return shape before alternatives and error details. The example payload and error verbosity are somewhat redundant with the existing output schema, so it is slightly longer than strictly needed, but no sentence is filler.
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?
Covers the prerequisite (free, no plan), the alternative tool and its paywall, the return shape, and error recovery — everything an agent needs to call it correctly. The presence of an output schema makes the inline return description a convenience rather than a gap.
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 schema already documents the slug and points to list_products, so the baseline is 3. The description adds value with a concrete worked example ({"slug": "brand-voice"} → skill/instructions payload) and by tying the slug to the list_products discovery path in the error text.
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?
States a specific verb and resource ('Load a product's free gateway skill with its complete instructions') and immediately contrasts it with the sibling get_full_skill, which handles the product's other named skills. An agent can distinguish this from get_full_skill and get_full_product without opening any schema.
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 names the use case ('Use when the caller wants usable instructions immediately') and the exclusion ('Not for the product's other skills... need get_full_skill with a skill_name, which requires a paid plan'). The alternative and the condition selecting it are both spelled out.
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 declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description earns credit for the extras it does add: the never-raises-a-protocol-error contract, the {"error": ...} shape, and retry safety after correcting input. It stops short of explaining the 'PREMIUM (license)' marker — whether a missing license surfaces as an error or different output is left unclear.
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?
Front-loaded with the core action and well ordered (purpose, example, return shape, alternatives, errors). There is minor redundancy: 'Returns persona plus every skill for one product' restates the opening sentence almost verbatim.
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?
With an output schema present the description does not need to enumerate return fields, yet it does so lightly; errors, alternatives, and safety are all covered. The only loose end is what the PREMIUM/license note means operationally for the caller.
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 slug parameter is already described as 'exactly as returned by list_products' with an example, so the description's worked input {"slug": "brand-voice"} mostly repeats structured data. Baseline 3 applies; no additional slug syntax or normalization rules are given.
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?
States a specific verb and resource — 'Load one product in full: its persona plus every paid skill' — which pins down both the scope and the exact payload. It is immediately distinguishable from get_full_skill (one skill) and list_products (free look).
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 says 'Use when the caller wants the whole product' and then names the two alternatives the caller should use instead, get_full_skill for a single skill and list_products / get_free_skill for a free look. The when-not conditions are spelled out, not implied.
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?
Goes beyond the annotations by disclosing the error contract: no protocol errors raised, a structured {"error": ...} payload is returned, and retry is always safe after correction, plus a PREMIUM/license signal. The licensing aspect is mentioned but not fully explained (e.g. what happens when unlicensed is left to the generic error shape), which keeps it short of a 5.
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?
Front-loaded with scope and licensing caveat, then examples, then routing and error behavior. There is minor redundancy between "Returns one named skill, selected by skill_name" and the preceding sentence, but nothing is wasted.
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?
An output schema exists so return values need not be detailed, yet the description still shows a representative response, plus error handling, retry safety, and sibling routing. An agent has everything needed to call this 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 both parameters documented, including provenance ("as returned by list_products"), so the baseline is 3. The description's example input conveys shape and value style but adds little semantic detail the schema does not already carry.
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?
States a specific verb and resource ("Load one paid skill's complete instructions from a product") and immediately differentiates itself from get_free_skill and get_full_product. An agent can identify the exact scope without opening the schema.
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?
Gives an explicit positive case ("Use when the caller wants one specific paid skill") plus two named exclusions with the sibling that handles each (free gateway skill → get_free_skill, all skills → get_full_product). No inference required.
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 readOnly/idempotent/non-destructive, but the description goes further by documenting the error contract: malformed input never raises a protocol error and instead returns {"error": ...} with remediation, so retry after correction is safe. It also discloses the scoring dimensions and that the service is free, which an agent would otherwise have to discover by trial.
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?
Front-loaded with the core action and limit, followed by cost, scoring criteria, an example, routing guidance, and error semantics in that order. Slightly verbose in restating a return shape that the output schema already covers, but no sentence is padding.
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 one-parameter read-only scorer with a declared output schema, the description covers purpose, limits, cost, error recovery, and sibling routing. An agent has everything needed to select and invoke it correctly on the first attempt.
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 single 'headlines' array parameter is already documented, so the baseline is 3. The description adds the 'up to 20' truncation behavior and a concrete example payload showing the plain-string array shape, which mildly exceeds the schema.
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?
States a specific verb pair (score and rank) on a specific resource (headlines), including the 20-item cap and the best-first ordering. It also explicitly names the sibling tools it is not (subject_line_scorer, analyze_writing), so an agent can disambiguate without opening schemas.
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?
Gives a positive trigger ('Use when several title options need ranking') and two explicit exclusions with the correct alternative for each: email subject lines go to the outbound server's subject_line_scorer, body prose goes to analyze_writing. Nothing is left to inference.
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?
Adds real context beyond the annotations: cost (FREE), that the payload is metadata only with no persona text or skill instructions, and a concrete error contract (never raises a protocol error, returns {"error": ...}) plus retry safety. It does, however, restate the read-only/idempotent hints the annotations already carry, and it doesn't note any pagination or size limits for a fixed 20-item result.
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?
Front-loaded with the core fact and the FREE signal, then the return shape, then routing exclusions. The error/retry paragraph is boilerplate-adjacent and "Takes no arguments" duplicates an empty schema, but no sentence is actively harmful.
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 trivial zero-arg lister, everything an agent needs is present: what it returns, how to use the returned slugs with the three follow-up tools, what it deliberately omits, when not to use it, and how failures surface. The output schema exists, so the inline object sketch is bonus rather than a gap-filler.
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?
Zero-parameter tool, so the baseline is 4. "Takes no arguments" is confirmed by an empty schema with additionalProperties: false, and the description correctly spends its budget on return shape instead of inventing parameter guidance.
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?
States a specific verb and resource ("List every product in the Creator Studio line with its included skills") and immediately bounds the scope with "FREE" and "metadata only." It is clearly distinguishable from get_full_product/get_full_skill, which fetch details for a single item, and from search_catalog, which searches a larger catalog.
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?
Gives an explicit positive trigger ("Use when the caller wants to see what this server covers") and two explicit exclusions with the named alternatives: keyword search belongs to search_catalog, and actionable instructions belong to get_free_skill. An agent can route without inference.
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?
Goes beyond the readOnly/idempotent annotations with two genuinely new behavioral facts: it is FREE, and it never raises a protocol error on bad input, instead returning an error object with fix guidance, making retry-after-correction safe. It does restate the annotation hints ('read-only and idempotent'), which is redundant, and the wpm parameter's behavioral effect (values below 60 clamped to 60) is left entirely to the schema.
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?
Front-loaded with the verb phrase and the free/read-only facts, followed by example, usage rule, and error contract in a logical order. The inline JSON input/output sample is slightly bulky relative to the information it conveys, given an output schema already exists.
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?
Covers purpose, alternative routing, error behavior, and retry safety — the pieces an agent actually needs — and an output schema exists so return values need little explanation. Completeness is only slightly undercut by not noting the wpm override, the one non-obvious input beyond the required text.
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%, so both parameters are already documented, and the baseline would be 3. The description adds value with a concrete typical-input example ('{"text": "<your article>"}') that shows the minimal viable call shape, though it never mentions the wpm knob, so it does not fully cover parameter space.
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?
States a specific verb and resource ('Estimate reading and speaking time plus basic content stats') and immediately differentiates from the sibling analyze_writing by naming what it does not cover (writing quality, grade level). An agent can select it without opening the schema.
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?
'Use when length and pacing are the question. Not for writing quality or grade level (analyze_writing)' gives an explicit when, an explicit when-not, and names the alternative tool. This is exactly the routing information an agent needs among the seven siblings.
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_writing1 field changedInput schema / properties / text / descriptionPrevious value: -"The draft to analyze — at least one full sentence; plain text,\nany length."New value: +"The draft to analyze, at least one full sentence; plain text,\nany length."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?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds material context beyond them: it discloses that invalid input never raises a protocol error and instead returns a structured {"error": ...}, and that retrying after a fix is always safe. It also flags the tool as free, which matters for an agent selecting among siblings.
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?
Front-loaded with the core action and platform list, then usage, then exclusions, then error contract — a sensible progression. It runs slightly long, with the error/retry sentence and the 'FREE' marker competing for attention, but no sentence is filler.
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 one-parameter read-only checker with an output schema, this is more than sufficient: scope, exclusions, example input/output, and error behavior are all present, so an agent can call it correctly on the first attempt.
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?
With a single parameter at 100% schema coverage, the schema already carries the semantics; the description still adds value by showing a concrete input shape ({"text": "<post>"}) and the corresponding result structure, making the call pattern obvious. It stops short of covering edge cases like empty text or non-string input.
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?
States a specific verb and resource ('check a post against every major platform's length limit at once') and enumerates the platforms covered, so an agent can distinguish it immediately from analyze_writing, headline_analyzer, and reading_time.
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 names the usage moment ('use before posting, to catch truncation') and rules out the two adjacent siblings by name: 'not for readability (analyze_writing)' and 'not for reading duration (reading_time).' Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.