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

Discloses read-only nature and filtering behavior (only authors with at least one published post). No annotations exist, so description carries full burden; could add more on rate limits or pagination, but sufficient for a browse 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?

Well-structured with sections (main, USE CASE, INCLUDE OPTIONS, NOTE, RETURNS). Every sentence adds value, no 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?

Covers return format, include options, and filtering. No output schema but description provides adequate return info. Lacks error handling or performance details, but acceptable for a browse tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is 100%, so baseline 3. Description adds context for the 'include' parameter (count.posts) but repeats schema info for 'limit'. Minimal added value beyond 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 explicitly states 'Browse public authors from Ghost Content API (read-only)' with concrete use cases, making the purpose clear. It distinguishes from siblings by resource name and mentions alternative tools (admin_browse_users) for staff without 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?

Provides explicit USE CASE examples and a NOTE about when to use an alternative (admin_browse_users for staff without posts), guiding the agent on 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?

No annotations exist, so the description carries full burden. It discloses read-only nature, public accessibility, only published pages, exclusion from RSS feeds, and pagination metadata. While it could mention rate limits or authentication, these are reasonably implied by 'read-only, public content' and the Ghost API context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is well-structured with clear sections (TIP, USE CASE, NOTE, RETURNS). It is concise, with every sentence adding information. No fluff or repetition. Front-loaded with purpose, making it easy to scan.

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 7 parameters and no output schema, the description covers the main output (array with pagination). It explains the tool's scope and limitations. Minor gaps include lack of error handling information or explicit mention of default limit value, but overall it is sufficiently complete for a read-only public endpoint.

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 baseline is 3. The description adds value beyond schema by explaining the fields parameter usage with examples, mentioning comma-separated for include/formats, noting default limit and order, and describing pagination behavior. This aids correct parameter selection.

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 browses published pages from Ghost Content API, specifying it is read-only and public. It lists specific use cases (static pages, site navigation, sitemap generation) and implicitly differentiates from siblings like content_read_page (single page) and content_browse_posts (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?

The description provides explicit when-to-use guidance with use cases, a tip for reducing response size, a note that it only returns published public pages (not drafts), and explicitly names an alternative: admin_browse_pages for drafts. This clearly helps the agent decide.

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 states the tool is read-only and public, and describes the return format (array with pagination metadata). It also includes filter examples. However, it does not mention rate limits, authentication, or the default value for limit in the description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is well-structured with sections (TIP, USE CASE, NOTE, FILTER EXAMPLES, RETURNS). Every sentence adds value, no fluff, and it is appropriately 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?

Given the complexity (7 parameters, no output schema, no annotations), the description covers purpose, usage, filtering, and return format. However, it does not specify the default limit value or mention other potential behavioral aspects like rate limits, so it's not fully exhaustive.

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%, baseline 3. The description adds value beyond schema with the TIP about using the 'fields' param to reduce response size, and concrete filter examples (tag:getting-started, featured:true, author:john) that are not in 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 verb 'browse' and resource 'published posts' from Ghost Content API, distinguishing it from sibling tools like content_browse_authors and content_browse_tags. It also contrasts with admin_browse_posts for non-public 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?

The description provides explicit use cases (frontend display, search by tag/author, RSS feeds) and explicitly states when not to use it (for drafts/scheduled posts, use admin_browse_posts). This gives clear guidance vs. 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?

With no annotations provided, the description carries the full burden. It states the tool is read-only, only returns public tags, and includes metadata and optional post counts. However, it does not disclose other behaviors such as authentication requirements, rate limits, or whether the tool is idempotent. Still, the read-only nature and public scope 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 is well-structured with clear sections (USE CASE, INCLUDE OPTIONS, NOTE, RETURNS). It is concise, front-loaded with the main purpose, and every sentence adds information. There is no 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?

Despite having 6 parameters and no output schema, the description covers the main purpose, use cases, return type (array of tags with metadata), and key behavioral notes (public only, including count.posts). It could mention pagination behavior more explicitly, but the param schema covers limit/page. Overall, it adequately prepares the agent for correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the include parameter (count.posts) and by restating the default for limit (15 or 'all'). This provides additional context beyond the schema, justifying a score of 4.

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 browses public tags from Ghost Content API, which is a specific verb+resource. It distinguishes from sibling admin_browse_tags by noting that this tool only returns public tags, and it lists concrete use cases like displaying a tag cloud or building navigation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly defines when to use the tool (displaying tags, getting post counts) and when not to use it (for internal tags, use admin_browse_tags). The note about internal tags provides clear exclusion criteria, and the use cases give clear context for appropriate invocation.

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 description fully covers behavior: read-only, only published posts, identifier constraint (id or slug, not both), and return summary (single object with bio, social links, optional post count).

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?

Well-structured with clear sections (purpose, use case, identifier note, limitation, returns). Every sentence adds value with 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?

For a single-read tool with 4 params and no output schema, the description adequately covers behavior, usage, constraints, and return type. Missing details like error handling for duplicate identifiers are minor given the clarity of the constraint.

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%, baseline 3. Description adds value by explicitly noting mutual exclusivity of id and slug ('Provide either 'id' OR 'slug', not both'), which is a constraint not in the schema. The include parameter's description matches the schema, so only moderate added value.

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 'Read a single public author by ID or slug (read-only)', specifying the action, resource, and identifier. It clearly distinguishes from sibling tools like content_browse_authors (listing) and content_read_page/tag/post.

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 explicit use cases (display author profile, get bio/social links) and a clear when-not-to-use condition: 'Only returns authors with published posts. For staff users without published posts, use admin_read_user instead.' This gives direct guidance on 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, so description bears full burden. It states read-only, public, only published pages returned, and mentions return type. Lacks explicit statement of no side effects or idempotency, but overall behavior is transparent.

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?

Structured with USE CASE, IDENTIFIER, NOTE, RETURNS headers. Front-loaded with purpose. Each sentence adds value, no filler. Could be slightly more concise, but overall well-organized.

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 detail return structure. It says 'Single page object with requested fields and related data,' which is vague. No mention of error handling or consistency guarantees. Adequate but lacking detail for full completeness.

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%, baseline 3. Description adds value by clarifying the mutual exclusivity of id and slug ('not both'), which is not in the schema. Also explains the purpose of the include and formats parameters implicitly.

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 'Read a single published page by ID or slug (read-only, public content).' It distinguishes itself from sibling tools like content_browse_pages (browsing) and content_read_author (different resource) by explicitly stating it's for a single page and public 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?

Includes explicit use cases, identifier constraint ('provide either id OR slug, not both'), and a note directing to admin_read_page for drafts/scheduled pages. This provides clear when-to-use and when-not-to-use guidance.

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

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

No annotations, so description covers read-only nature, public access, only published posts, and return structure. Could add details on rate limits or auth, but sufficient for a read-only public endpoint.

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?

Well-structured with sections, no redundant sentences, front-loaded key info, and only essential details.

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 but description adequately describes return (single post object with requested fields and related data). All aspects of usage and constraints are covered.

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 100% but description adds value: explains id/slug mutual exclusivity and the purpose of include, fields, and formats parameters.

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?

Clear verb 'Read' and resource 'single published post'. Distinguishes from siblings (different resources: pages, tags, authors) and explicitly mentions admin_read_post for draft/scheduled 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?

Provides explicit use cases, mutual exclusivity of id/slug, access constraint (published only), and alternative for drafts via admin_read_post.

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 behavior and notes that only public tags are returned. Despite no annotations, it fully discloses the tool's constraints and return type, adding context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Concise, front-loaded with the main action, and uses clear section headers (USE CASE, IDENTIFIER, NOTE, RETURNS). Every sentence earns its place with zero 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?

Despite no output schema, the description specifies the return type (single tag object with metadata and optional post count). Covers use cases, constraints, and distinguishes from siblings. Fully adequate for the tool's simplicity.

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 baseline is 3. The description adds the exclusive constraint on id/slug and hints at include parameter usage, providing meaningful extra context. Lacks elaboration on fields parameter.

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 (read), resource (public tag), and identification methods (ID or slug). It distinguishes itself from the sibling browse tools and explicitly mentions the alternative admin_read_tag for internal tags.

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 explicit use cases (display tag details, SEO), clear constraint on identifier (provide id or slug, not both), and directs to admin_read_tag for internal tags. Excellent guidance.

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