Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description declares read-only behavior, which is good. However, without annotations, it should also disclose other traits like result format or pagination. It mentions 'limit' implicitly but does not explain full behavior. Score 3 indicates adequate but not rich disclosure.

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?

Two sentences, no wasted words. The description is front-loaded with the essential read-only declaration and resource. Every sentence earns its place. Perfectly concise.

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 5 parameters, no output schema, and no annotations, the description covers basic purpose and filtering logic but lacks details on parameter formats (e.g., date format for 'since') and output structure. It is minimally complete but has gaps.

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 0%, so the description must compensate. It adds that filters compose with AND, which is useful. However, it does not elaborate on individual parameter semantics beyond their names and default values. The AND composition is the only added meaning.

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?

Clearly states the tool is read-only and queries the audit.jsonl of every write. The verb 'Query' and resource 'audit.jsonl' are explicit. The description distinguishes it from sibling content-operation tools.

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 does not explicitly specify when to use this tool versus alternatives. It is implied for auditing writes, but no usage context or exclusions are provided. A 3 reflects the lack of explicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses key behaviors: it writes to a local file, uses a local LLM, and outputs JSON with action='pending'. It does not detail error handling or file overwriting, but it is sufficiently transparent for the intended use.

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 highly concise, using a single sentence plus a brief note on output and workflow. Every word serves a purpose with 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 tool's simplicity (3 parameters, no output schema, no annotations), the description is largely complete. It covers the core function, output format, and next steps. Missing error behavior, but overall adequate.

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 input schema has 0% description coverage, so the description must compensate. It implicitly covers post_id (via 'every response on a post') and out (via output file default), but does not mention the model parameter. This partial coverage justifies a score of 3.

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's purpose: it writes to a local file, generates reply drafts for every response on a post using a local LLM, and specifies the output format. It distinguishes itself from sibling tools like send_approved_drafts by outlining the workflow.

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 clear context: it is a local operation ('no Medium call'), and it instructs the user to edit the output then run send_approved_drafts. This implicitly defines when to use it, though it does not explicitly list when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses: mutation (WRITE), fragility (undocumented endpoint), idempotency (dedup-protected), and safety (dry-run default). No contradictions with annotations (none provided).

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?

Two short sentences, front-loaded with 'WRITE'. Every sentence carries essential information: action, range, fragility, dedup protection, default behavior. No wasted words.

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?

Despite no output schema and no annotations, the description covers purpose, usage hints, and key behavioral traits. Could mention return value or error handling, but for a simple clap action, this is adequate. The context is complete enough for an AI agent to invoke 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 description coverage is 0%, so description must compensate. It adds value by stating '1-50 times' for claps (range) and 'Dry-run by default' for dry_run. Post_id is not explained, but titles and defaults in schema mitigate this. Overall, description provides useful parameter context beyond schema titles.

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 starts with 'WRITE' indicating action type, then 'Clap a story 1-50 times' clearly specifies verb and resource. The mention of 'undocumented dashboard endpoint — fragile' adds operational context. This distinguishes it from siblings like get_clap_count (read) and publish_post (publish).

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?

Description states 'Dedup-protected per post' implying repeated calls are safe, and 'Dry-run by default' indicates actual clapping requires setting dry_run=false. It does not explicitly list when to use vs alternatives, but the context is clear enough for an AI agent to infer usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description provides key behavioral traits: idempotent and single-use tokens. However, it omits details like error handling, authentication needs, or return format. It is adequate but not comprehensive.

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 brief (two sentences) and front-loaded with the primary action. Every sentence adds value without redundancy. It is efficiently structured for quick comprehension.

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 simple input schema and no output schema, the description covers the core purpose and behavior. However, it lacks details about prerequisites (e.g., how to get a token), what 'force' does, and what the response or side effects are. It meets minimal requirements but leaves gaps.

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 description mentions 'token' in context but does not explain what it is or where to obtain it. The 'force' parameter is not mentioned at all. With 0% schema description coverage, the description fails to add sufficient meaning beyond 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?

The description clearly states the action ('EXECUTE the staged write') and lists specific steps (look up token, post to Medium, log, persist dedup row). It distinguishes from sibling tools like propose_reply by indicating this is the final confirmation step.

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 mentions idempotency and token single-use, which inform usage constraints, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. The guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses read-only behavior and purpose. Could be slightly more explicit about lack of side effects, but 'Read-only' suffices.

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?

Two concise sentences, front-loaded with key attribute 'Read-only.' No extraneous content; every phrase serves a purpose.

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 parameterless tool with no output schema, the description fully covers purpose, usage context, and relationship to sibling. No gaps.

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?

No parameters exist; schema coverage is 100% vacuously. Description adds value by specifying the sources counted (claps, responses, publishes) beyond the empty 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?

The description clearly states it is a read-only tool that counts from a local dedup SQLite DB to prevent duplicate writes. It distinguishes itself from siblings like audit_search.

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: after writes to confirm ledger advanced, or if a write skipped. Mentions alternative audit_search for status='deduped'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Declares read-only nature and maximum claps per clapper. With no annotations, it discloses key behaviors clearly, though missing potential error states or rate limits.

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?

Two sentences, highly efficient, with front-loaded 'Read-only' qualifier and no wasted words.

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, behavior, and usage context for a simple tool. Could mention result format or error handling, but overall adequate given no output schema.

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?

Parameter post_id is not mentioned in the description despite 0% schema coverage. The description adds no explanation beyond the schema field name, leaving the agent to infer its meaning from context.

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 returns total claps on a single story, with specifics like max 50 per clapper. It explicitly distinguishes from get_post by noting speed and scope.

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?

Provides a concrete use case (engagement checks before/after posting a response) and compares with get_post for efficiency. Lacks explicit 'when not to use' but context is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Declares 'Read-only' upfront, but lacks disclosure on pagination, rate limits, or response structure; no annotations provided so description carries full burden.

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?

Extremely concise, single sentence with front-loaded key info ('Read-only') and an example, no wasted words.

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 and parameter values adequately for a simple feed tool, but omits output format or error handling; no output schema to compensate.

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?

Adds meaning to the 'tab' parameter by explaining possible values, but does not clarify the 'limit' parameter beyond its default; schema has 0% description coverage.

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 is a 'Reader feed' with specific tab options ('home', 'following', 'tag-{slug}'), distinguishing it from sibling tools like get_post or search_posts.

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 lists valid tab values with an example, but does not provide when to avoid using this tool or compare to alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description discloses it is read-only and mentions the API source (dashboard GraphQL API). While it could discuss error cases or authentication details, for a simple profile retrieval the disclosure 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no fluff. Front-loaded with key info: 'Read-only. Return the authenticated user's profile...'. Every sentence adds value.

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?

Without an output schema, the description enumerates returned fields. Combined with usage context, it fully covers what the agent needs to know for this simple 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?

No parameters exist, so schema coverage is 100%. The description does not need to add parameter info. Baseline 4 for zero parameters 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 specifies the tool returns the authenticated user's profile, listing specific fields (id, username, name, bio, follower/following counts). It distinguishes from the sibling tool get_profile by noting it takes a @handle for other users.

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 this tool ('who am I' context for downstream calls) and when to use the alternative (get_profile for any other user). Provides clear decision guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description declares read-only behavior and provides ID format example. It does not cover errors or auth, but for a simple read tool this is solid. Adds context beyond the bare 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?

Three compact sentences: functional header, data fields, cross-references. Every sentence adds distinct value without repetition. Ideal length.

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 no output schema, the description lists returned fields. It also informs about what is not included (body, comments) and directs to relevant tools. Covers all essential aspects for a single-param retrieval 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 has 0% coverage, but description adds value by specifying the ID format (12+ char hex) and giving an example. This helps the agent construct correct inputs beyond just the parameter name.

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 verb (read-only retrieval) and resource (story metadata by post id), lists returned fields, and distinguishes from sibling tools by mentioning get_post_content and list_responses. This makes the 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 provides when to use this tool (for metadata) and when to use alternatives (get_post_content for body, list_responses for comments). Also indicates read-only nature, guiding appropriate usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description carries full burden. It declares read-only and mentions a requirement for member sid for members-only stories. However, lacks details on authentication, rate limits, or any side effects. The read-only claim is helpful but incomplete.

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?

Three sentences, front-loaded with key info (read-only). No wasted words. Efficient structure.

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?

No output schema, so description should elaborate on return format. It says 'story body as HTML' and mentions Markdown conversion, but doesn't specify if it's full document or fragment. With sibling tools like get_post, it's somewhat complete but could clarify more.

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 0%, so description must compensate. It explains as_markdown parameter and implies post_id is the target. However, post_id's format or constraints are not described, and both parameters lack full semantic context. Adds some value but not fully compensating.

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 it returns story body as HTML and mentions Markdown conversion. It distinguishes itself from siblings like get_post (metadata) and search_posts. However, it could be more explicit about the specific resource being the body content.

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?

No guidance on when to use this tool versus alternatives like get_post or search_posts. The condition about members-only stories needing a member sid is noted but no broader usage context is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Starts with 'Read-only' which is a key safety trait. Indicates it's a public profile, implying no authentication needed. Lacks explicit mention of error cases or rate limits, but given simplicity, the main behavioral traits are well-covered.

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?

Two concise sentences—first states purpose and return fields, second gives usage guidance. No fluff, highly efficient.

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 (1 param, no output schema), the description covers purpose, return fields, and provides follow-up tool suggestion. It is fully adequate for an agent to select and invoke 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?

Only parameter 'username' has no schema description (0% coverage). Description says 'by @username' but does not clarify if the '@' should be included, nor provides any additional constraints or format guidance beyond the schema's type string.

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 it retrieves a public profile by username, listing returned fields (id, name, bio, follower count). It distinguishes from get_own_profile by mentioning 'public profile' and later contrasting with authed user.

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 suggests using list_posts after this for stories, and recommends get_own_profile for the authenticated user, providing clear when-to-use and when-not-to.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description declares read-only but lacks details on pagination, error handling, or rate limits. With no annotations, the description could disclose more behavior.

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?

Two sentences, front-loaded with 'Read-only.' Every sentence adds value; no wasted words.

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?

Despite missing parameter semantics, the description provides sufficient workflow context for the tool's low complexity, though behavioral details are lacking.

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 0% and the description does not explain the parameters (response_id and limit) beyond referencing response IDs from list_responses. No added meaning over 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?

The description clearly states it retrieves nested replies under a single top-level response and distinguishes from list_responses by indicating the workflow.

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 instructs to use list_responses first to get response IDs, then call this tool per response to walk the thread, providing clear when-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explicitly states the tool is read-only and requires an sid cookie for dashboard access, adding important behavioral context beyond the missing annotations. It does not detail response behavior or error cases, but it covers the key constraints.

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 extremely concise with two sentences, front-loading the core purpose and read-only nature. Every part adds value without 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 tool's simplicity (one param, no output schema, no annotations), the description covers purpose, parameter, and authentication. However, it lacks clarity on whether stats are for a specific post or the user's entire dashboard, which is important context.

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 only parameter 'days' has no schema description, but the description clarifies it means 'the last N days', adding meaning. It could mention the default value or acceptable range, but it is sufficient for basic usage.

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 retrieves per-post stats (views/reads/fans) for a time range, distinguishing it as a stats tool among siblings. However, it does not specify which post or user context, leaving some ambiguity.

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?

No guidance is provided on when to use this tool versus alternatives like get_post or get_clap_count. The description only notes the requirement for an sid cookie, but no explicit when-to-use or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full responsibility. It explicitly states 'Read-only', which is critical for safety. It also discloses the filtering logic (unanswered by authed user). No additional behavioral traits (e.g., pagination) are mentioned, but the core safety and filtering are well communicated.

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 consists of two short sentences. The first sentence is front-loaded with 'Read-only' and states the core purpose. The second provides workflow guidance. No wasted words; every sentence adds value.

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 2 parameters and no output schema, the description covers purpose and workflow but omits parameter details and return format. While the core functionality is clear, the agent lacks information about what the response contains, which could lead to errors in downstream processing.

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 0%, so the description must compensate. However, it does not mention the two parameters (post_id, limit) or their semantics. The agent must infer meaning from names alone, which is insufficient for precise usage.

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 explicitly states 'Return responses on a post where the authed user has NOT yet replied', clearly identifying the verb (return), resource (responses on a post), and specific filtering condition. It distinguishes from siblings like 'list_responses' or 'get_response_replies' by the unique filter.

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 a complete workflow: 'Canonical worklist: read each, draft a reply in your context, then propose_reply -> confirm_reply.' This explicitly tells the agent when and how to use the tool within a sequence, though it does not explicitly exclude alternative uses.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description declares the tool as read-only, which is a key behavioral trait. It also specifies the authentication requirement (Medium integration token). Without annotations, it effectively discloses the essential behaviors, though it lacks details on potential limitations like pagination or rate limits.

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 extremely concise at two sentences, with the most critical information (read-only nature) placed first. Every sentence adds value without waste.

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 (zero parameters, no output schema), the description is complete. It covers purpose, return format, usage recommendation, and auth requirement, leaving no obvious gaps for the 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?

The input schema has zero parameters, so no parameter documentation is needed. The description adds no parameter-specific info, but the baseline for no parameters is 4. The description compensates by explaining the return value and usage context.

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 lists publications where the user can publish as editor/writer, and specifies the return format (id + name pairs). It distinguishes from siblings like list_posts and list_responses, which serve different purposes.

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 explains that the id can be used with publish_post's publication_id, providing actionable guidance. It does not explicitly mention alternatives, but no other sibling tool lists publications, so the context is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description only states 'Read-only' but does not elaborate on traits such as pagination, time window for 'recent', or any constraints. With no annotations provided, the burden falls on the description, which falls short.

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 extremely concise—only 7 words—and every word is meaningful. The 'Read-only' prefix is front-loaded for immediate safety signals. No wasted text.

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 2 optional parameters, no output schema, and no annotations, the description is too brief. It lacks details on parameter semantics, result format, or behavioral constraints (e.g., rate limits, ordering).

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 input schema has 2 parameters (limit, username) with 0% coverage in the description. The description adds no information about what these parameters control or their effects, forcing the agent to infer from defaults alone.

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 action (list), the resource (recent stories), and scope (by a user, default self). It also adds 'Read-only' to indicate safe operation, distinguishing it from mutation tools.

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?

While the description implies usage for listing recent stories of a specific user, it provides no explicit guidance on when to use this tool versus siblings like search_posts or get_feed. No when-not-to-use or alternatives mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes itself as 'Read-only', clarifying safety. Mentions it returns top-level responses only, not replies, which is key behavioral context. No annotations provided, so description carries burden well.

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?

Three concise sentences, each serving a purpose: declaring read-only nature, describing the result set, and guiding to alternative tools. No wasted words.

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 list tool with 2 parameters and no output schema, the description provides enough context: what it does, how results can be used, and alternatives. No major gaps.

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 has 0% description coverage for parameters, and the description does not explain post_id or limit beyond the schema field names. No clarification of what post_id refers to or how limit works.

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?

Clearly states it lists top-level responses under a story, distinguishes from sibling tools get_response_replies and get_unanswered_responses. Verb 'list' + resource 'responses' with context 'under a story'.

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 tells when to use alternatives: prefer get_unanswered_responses for filtered worklist, and explains how to use response ids with get_response_replies for replies.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description discloses the mutation nature (WRITE), endpoint fragility, and default dry-run behavior. It lacks details on auth or error states but adequately covers key traits.

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?

Three concise sentences: purpose, fragility warning, and usage guidance. Every sentence adds distinct value, front-loaded with the core verb and object.

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 4 parameters (2 required) and no output schema, the description covers purpose, use cases, preferred alternative, and default. It could elaborate on parameter specifics but is fairly 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It clarifies the use of post_id for top-level and parent_response_id for replies, and mentions dry_run default. However, it does not explicitly map each parameter to its role.

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 explicitly states the verb ('Post') and the resource ('top-level response under a story, or a reply under a response'), distinguishing between two use cases. It also contrasts with sibling tools like propose_reply and confirm_reply.

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 provides explicit guidance: prefer propose_reply -> confirm_reply for interactive drafting, and notes the dry-run default. It also warns about the fragility of the endpoint, implying when to avoid.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description bears full burden. It discloses behavior: it's a write but not final, dedup hash computation, token storage, 5-minute expiration, preview return, and linkage to confirm_reply. Lacks details on error cases or rate limits, but sufficient for basic understanding.

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?

Four sentences, front-loaded with the key term 'STAGE A WRITE'. Every sentence provides unique information without redundancy. Efficient and well-structured.

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 no output schema, description explains the two-phase flow, token expiration, and the need to call confirm_reply. Could mention how the token is returned or used, but overall sufficiently complete for a complex workflow.

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 0%, so description must add meaning. It explains parent_response_id's role (reply under specific response vs top-level). For post_id and body, it adds minimal value beyond the schema's type and required flags; body validation is implied but not detailed. Adequate but not exceptional.

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?

Clearly states it stages a write (not final), validates, computes dedup hash, stores under token, returns token+preview. Distinguishes from siblings like confirm_reply and post_response by describing the two-phase commit pattern.

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 'STAGE A WRITE (no Medium call yet)' and 'On approval call confirm_reply', guiding the agent to use this for proposing before finalizing. Tokens expire in 5 minutes. Does not explicitly list alternatives or when not to use, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses action type (WRITE), default draft status, dry-run behavior, and use of integration token. No output schema exists, but description hints at publish consequences. Lacks detail on what happens on success or side effects like follower notifications.

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?

Three short sentences, each valuable. Front-loaded with action and resource. No redundancy or fluff.

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?

Adequate for a complex tool with 8 parameters and no output schema. Missing explanation of return value or authentication requirements beyond 'uses integration token'. No reference to required fields (though in schema).

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 0% schema description coverage, description adds meaning for content_format, publish_status options, and dry_run default. Does not explain tags, publication_id, canonical_url, or notify_followers, leaving half of 8 parameters undocumented.

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 'WRITE. Publish a story.' with specific verb and resource. Specifies content_format as markdown and distinguishes from sibling tools like 'clap_post' or 'post_response' by focusing on publishing.

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?

Explains default status behavior ('nothing goes public by accident') and how to override with 'public' or 'unlisted'. Mentions dry-run default but does not explicitly compare to other publish-related tools or list prerequisites like authentication.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description labels the tool as 'Read-only', which is a positive disclosure. However, with no annotations, it fails to elaborate on other behavioral aspects such as authentication requirements, rate limits, or pagination behavior, relying solely on this single trait.

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, consisting of a single sentence with no redundancy. However, the inclusion of the ambiguous 'Medium-side' undermines clarity, and the structure lacks specifics beyond the read-only note.

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 (two parameters, no output schema, no annotations), the description is insufficient. It does not specify the search scope (e.g., what constitutes 'public stories'), result ordering, or return structure, leaving significant gaps for correct agent invocation.

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 parameters 'query' and 'limit' are left entirely undescribed in both schema and description. The description only mentions 'search' but does not clarify what the query should be or how the limit affects results, offering zero additive value for parameter semantics.

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 'search across public stories', which clearly identifies the tool's purpose as a search function. However, the term 'Medium-side' is vague and may confuse, and it does not explicitly differentiate from sibling tools like list_posts or get_feed.

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?

No guidance is provided on when to use this tool versus alternatives. The description does not mention any context or conditions for appropriate use, leaving the agent without decision support.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 that the tool performs a write operation, processes sequentially, respects a rate_seconds throttle, and defaults to dry-run. However, it does not detail side effects (e.g., error handling, impact on drafts.json file) or whether the operation is reversible.

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 two sentences long with no wasted words. The first sentence ('WRITE.') immediately signals the action type, followed by a concise behavioral summary. Every element serves a purpose, making it highly efficient for an AI agent to parse.

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 no output schema and moderate parameter count, the description covers the core behavior well. However, it omits details about the 'force' parameter, potential error scenarios, and the structure of drafts.json. These gaps could hinder an agent's understanding in edge cases.

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 0%, so the description must compensate. It explains the purpose of 'drafts_path' (file containing approved entries), 'rate_seconds' (throttle), and 'dry_run' (default behavior). However, the 'force' parameter is not mentioned, leaving its meaning unclear. Overall, the description adds significant context beyond the schema's names and types.

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 explicitly states 'WRITE. Sequentially post every entry in drafts.json where action=="approved".' This clearly identifies the action (post), resource (drafts.json entries with 'approved' action), and behavior (sequential, throttle). It distinguishes from sibling tools like 'publish_post' by specifying a specific data source and filtering condition.

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 implies usage for posting approved drafts with a dry-run default, but it does not explicitly state when to use this tool versus alternatives (e.g., publish_post, post_response). No exclusion criteria or alternative suggestions are provided, leaving the agent to infer context from the tool's specifics.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries full burden. It declares read-only behavior and credentials verification, but lacks details on side effects or rate limits. Adequate for a simple test tool.

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?

Two efficient sentences: first covers purpose and output, second gives usage guidance. No wasted words.

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 zero parameters and no output schema, the description fully explains the tool's function and return values. Complete for its purpose.

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?

No parameters exist, so schema coverage is 100% trivially. The description adds no param info, but none is needed. Baseline 4 for 0 params.

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 is read-only, verifies credentials, and returns user info and publication count. It distinguishes itself from siblings as the only connection test tool.

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 advises 'Call this first if other tools 401', providing clear context for when to use it. No alternatives needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.