Server Quality Checklist

Tool Scores

• get_postA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description adds useful context by requiring the 'posts:read' scope and noting included fields (content_html/content_json and SEO fields). However, it does not disclose behavior for non-existent IDs, error responses, or output format, leaving gaps.

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

  Conciseness5/5

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

  The description is two sentences with no redundant wording. It front-loads the main action and then adds the auth requirement in a separate concise sentence, making it efficient and easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity (single parameter, no output schema, simple read), the description is mostly complete: it covers the core operation, auth scope, and returned fields. It lacks explicit error handling details, but these are not critical for a simple fetch.

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

  Parameters3/5

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

  The schema already fully describes the single 'id' parameter with 100% coverage. The description repeats 'PocketBase record ID' but does not add additional semantics beyond the schema, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it 'Fetches a single post by its PocketBase record ID', which is a specific verb+resource+scope. It distinguishes from list_posts (single vs. list) and sibling mutation tools like create_post and update_post.

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

  Usage Guidelines3/5

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

  Usage is implied for retrieving a single post by ID, but no explicit alternatives or exclusions are mentioned. The description does not say when to prefer this over list_posts or other siblings, providing only implicit context.

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

• moderate_commentA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses a key behavioral trait (requires the comments:moderate scope) and indicates a mutation action. However, it does not explain side effects, reversibility, or what the response looks like, which would be valuable for an agent.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core purpose, and includes only necessary details (allowed statuses and scope requirement). No redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter setter, the description covers purpose, statuses, and required scope. While there is no output schema and no mention of return behavior, the simplicity of the operation makes this mostly complete. A brief note on alternatives to sibling post-moderation tools would have pushed it higher.

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

  Parameters3/5

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

  Schema coverage is 100%, with clear descriptions for both id and status, and the status enum is also present. The description adds no additional parameter-level meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action ('Sets a comment's moderation status') and enumerates the allowed statuses (approved, pending, or spam). This specific verb+resource combination, along with the title 'Moderate a comment', effectively distinguishes it from sibling tools that operate on posts.

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

  Usage Guidelines3/5

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

  The description implies the tool is for moderating comments, and the scope requirement provides a prerequisite context. However, it does not explicitly compare to alternatives like update_post or publish_post/unpublish_post, nor does it state when not to use this tool.

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

• delete_postA
  3.9/5.0
  Behavior4/5

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

  With no annotations, the description carries the transparency burden. It discloses the destructive and irreversible nature ('Permanently deletes') and the required scope, covering the most critical behavioral traits. It does not mention side effects on related data or response behavior, but the key safety profile 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.

  Conciseness5/5

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

  The description is a single sentence, front-loaded with the action, and contains no extraneous words. Every phrase is necessary and informative.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple, but the description omits what happens on success (e.g., return value) and any effects on related resources like comments or media. Without an output schema, this additional context would be helpful. The core behavior is clear, but some operational details are missing.

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

  Parameters3/5

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

  The schema's parameter description already fully documents the 'id' parameter as 'PocketBase record ID of the post to delete.' The tool description only repeats 'by ID' without adding new semantic value, so it meets the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Permanently deletes a post by ID,' which is a specific verb+resource action. This distinguishes it from sibling tools like update_post, publish_post, and unpublish_post.

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

  Usage Guidelines3/5

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

  The description implies usage (for deleting a post) but does not explicitly say when to prefer this over alternatives like unpublish_post. It provides a prerequisite ('Requires the posts:write scope') but no clear when-to-use or 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.

• list_membersA
  4.1/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses pagination, email masking (a data transformation trait), optional tier filtering, and the members:read scope requirement. It does not describe the response structure or error/rate-limit behavior, but for a list operation these are less critical. The masking and scope details go beyond the schema, providing useful behavioral transparency.

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

  Conciseness5/5

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

  The description is two sentences and efficiently conveys core functionality, pagination, masking, filtering, and auth. No redundant words; every clause adds information. It is front-loaded with the main verb and resource.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a list tool with no output schema or annotations, the description covers purpose, pagination, filtering, masking, and auth. However, it does not describe the response format (e.g., array of members with pagination metadata), which would be helpful given no output schema exists. The description is helpful but not fully complete in this dimension.

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

  Parameters3/5

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

  The schema already provides complete descriptions for all three parameters (page, tier, perPage) with defaults, ranges, and enum values. Schema coverage is 100%. The description mentions tier filtering and pagination but does not add new parameter-specific semantics beyond the schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Lists reader/subscriber records, paginated.' It provides a specific verb (lists), resource (reader/subscriber records), and key contextual details (email masking, tier filter, required scope). The resource is unique among siblings (members vs posts/media/comments), so it distinguishes itself effectively.

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

  Usage Guidelines4/5

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

  The description clearly indicates this is for listing reader/subscriber records, implying use when member data is needed. It mentions the optional tier filter and required scope, giving context. However, it does not explicitly compare to sibling list tools (e.g., 'for posts use list_posts'), so it lacks explicit exclusions or alternatives. Usage context is clear but not exhaustive.

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

• list_commentsA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It discloses pagination, optional filters, and authentication requirements (comments:read scope). It does not detail response shape or ordering, but for a read-only listing tool this is adequate.

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

  Conciseness5/5

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

  Two concise sentences front-load the primary action, pagination, filters, and scope. Every clause earns its place with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a moderately simple listing tool with no output schema and no annotations, the description covers purpose, filters, pagination, and auth. It lacks return-format details, but the schema covers parameters and the tool is not behaviorally complex, so it is adequately complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal semantic value beyond restating the filter options and pagination. It does not introduce new parameter meaning, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Lists') and resource ('comments'), with clear scope markers: pagination, optional filters, and required scope. It distinguishes itself from siblings like moderate_comment (which alters comment state) and list_posts (which lists posts).

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

  Usage Guidelines4/5

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

  The description clearly implies when to use this tool: to retrieve comments, optionally filtered by post or moderation status, and requires the comments:read scope. It does not explicitly name alternatives or exclusions, but the context makes the usage straightforward.

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

• list_mediaA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description discloses key behaviors: pagination, optional filtering by MIME type, and the required 'media:read' scope. It does not detail return structure, but covers the main behavioral aspects for a list operation.

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

  Conciseness5/5

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

  The description is three concise sentences that each add value: purpose, filtering, and auth requirement. It is front-loaded and free of filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers purpose, pagination, filtering, and scope, but omits return format details. Given no output schema, a bit more specificity about the response would improve completeness, but the essentials are present.

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

  Parameters3/5

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

  The schema covers all three parameters with detailed descriptions (page, type, perPage). The description's mention of 'MIME type prefix (e.g. 'image')' merely repeats the schema's existing example, adding no additional semantic value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Lists items in the media library' with a specific verb and resource, and distinguishes from sibling list tools (list_posts, list_comments, list_members) by specifying 'media library' and the MIME type filter.

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

  Usage Guidelines4/5

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

  The description provides clear context by defining the resource as 'media library' and noting optional MIME type filtering, making its intended use obvious. It does not mention alternatives or exclusions, but none are necessary given the distinct resource.

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

• list_postsA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full behavioral burden. It discloses pagination behavior (default 20/page, max 100), optional status filtering, and the required API key scope. This goes well beyond a simple 'list posts' statement, providing useful operational details.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the primary action, and every sentence adds value. It efficiently covers the core function, pagination, filter, and scope without any fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is sufficiently complete for a simple list tool with three optional parameters and no output schema. It covers the essential context: what it lists, pagination limits, available filters, and authentication requirement. It does not describe response shape, but this is not critical for a list operation and no output schema exists to contradict it.

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

  Parameters3/5

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

  The schema description coverage is 100%, so all parameters are already documented (page, status, perPage). The description mostly restates what the schema says (default 20/page, max 100, status filter) without adding new meaning or clarifications beyond the structured schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's verb and resource: 'Lists blog posts for the authenticated tenant.' It also specifies pagination and optional status filtering, which distinctly separates it from sibling tools like get_post (single post) and create_post/update_post/delete_post (mutations).

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use the tool: to list posts with pagination and optional status filters, requiring posts:read scope. It does not explicitly mention alternatives or exclusions, but the context is sufficient for an agent to understand its typical use case compared to sibling tools.

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

• publish_postA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the transparency burden. It reveals that publishing changes the status to 'published' and adds a 'published_at' timestamp, plus requires the 'posts:write' scope. This provides meaningful behavioral context beyond the tool's name and helps the agent understand side effects and authorization needs.

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

  Conciseness5/5

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

  The description is two concise sentences, front-loading the action and effect in the first sentence and the shorthand relation in the second. Every word serves a purpose, with no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple status-change tool with one parameter and no output schema, the description covers the core action, effect, and required scope. It could add a note about what happens if the post is already published or that only the status field is affected, but the shorthand reference to update_post implies this, making it nearly complete.

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

  Parameters3/5

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

  The only parameter (id) is already described in the schema as 'PocketBase record ID of the post to publish', giving 100% schema coverage. The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline for full coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Sets' with an explicit resource ('a post's status') and the effect (to published, stamps published_at). It clearly distinguishes from siblings like update_post and unpublish_post by describing the exact mutation performed.

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

  Usage Guidelines4/5

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

  The description explicitly frames the tool as 'Shorthand for update_post({ status: 'published' })', giving clear guidance on when to use it as a specialized alternative to updating the status directly. It also mentions the required scope ('posts:write'), which helps in deciding eligibility, though it doesn't explicitly exclude using update_post for other field changes.

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

• update_postA
  4.2/5.0
  Behavior4/5

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

  Discloses the sparse-update behavior (only passed fields changed), the validation constraint (at least one field besides id), and the required scope. No annotations are provided, so these disclosures are valuable. However, it omits return-value behavior and side effects like the published_at stamp, which are covered in the schema's status description.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the core action and scope. Each sentence adds information: what it does, the field requirement, and the required permission.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 10-parameter mutation tool with no annotations and no output schema, the description covers the essential usage contract: partial update, minimum field requirement, and scope. It could explicitly advise using publish_post/unpublish_post for status-only changes, but that guidance exists in the schema's status parameter. Return-value information is missing but not critical.

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

  Parameters3/5

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

  Schema description coverage is only 30%, so the description needed to compensate. It adds the key semantic that all optional properties are updatable individually, and the 'at least one field besides id' requirement clarifies the role of the id parameter. It doesn't describe individual parameters, but the names are self-explanatory and the partial-update contract ties them together.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states it partially updates an existing post, distinguishing it from create/delete. 'Only the fields you pass are changed' adds precision. Also includes the required scope.

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

  Usage Guidelines4/5

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

  Provides clear context that it is a partial update and requires at least one non-id field, plus posts:write scope. It doesn't explicitly name alternatives like publish_post/unpublish_post, which are referenced in the schema's status description rather than the tool description.

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

• create_postA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the transparency burden. It discloses the default status, auto-stamping of published_at, and the two-step draft workflow, plus the required posts:write scope. It doesn't cover error behavior or return value, but the key behavioral traits are well explained.

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

  Conciseness5/5

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

  Two sentences deliver purpose, behavior, alternatives, and prerequisites. Perfectly front-loaded, with no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 9 parameters and no output schema, the description works well with the schema to cover all essential inputs and the publishing workflow. The only gap is not describing what the tool returns (e.g., created post object), which would be helpful without an output schema.

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

  Parameters3/5

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

  Schema description coverage is 78%, and the schema already details all major parameters. The description adds workflow context (default status, publish_post alternative) that partially reinforces the schema's status description but doesn't add new parameter-specific semantics beyond what's already documented.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Creates') and resource ('blog post'), clearly distinguishing this from siblings like update_post, publish_post, or list_posts. It also clarifies the default status and publishing workflow.

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

  Usage Guidelines5/5

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

  Explicitly states when to use publish_post vs. immediate publishing: 'create as a draft and call publish_post once you're ready.' Also names the required scope, giving clear context for when this tool is appropriate.

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

• get_site_settingsA
  4.5/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. It explicitly states which fields are returned, that encrypted fields are always excluded, and the required auth scope. This gives the agent a strong behavioral model for a simple config fetch.

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

  Conciseness5/5

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

  Two sentences with high information density. Front-loads the main purpose, then adds the critical exclusion and auth caveats. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless read-only tool with no output schema, the description fully covers return contents, exclusions, and access requirements. Nothing essential missing.

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

  Parameters4/5

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

  Zero parameters, so baseline is 4 per rubric. Description correctly spends no space on parameters; schema already documents the empty property set.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Specific verb 'Fetches' plus resource 'tenant's site configuration' with concrete examples (name, description, logo, favicon, flags). Unambiguous and clearly distinct from sibling tools like get_post or list_members.

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

  Usage Guidelines4/5

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

  Clear context of what the tool retrieves and the required scope. No explicit 'when to use vs alternatives' is needed because no sibling tool overlaps with site settings; the purpose itself implies the usage context.

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

• unpublish_postA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the state transition ('back to draft'), the public-facing consequence ('taking it off the public site'), the relationship to update_post, and the required auth scope. It does not mention potential failure modes or return values, but for a simple idempotent-looking operation this is reasonably transparent.

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

  Conciseness5/5

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

  The description is two sentences long, front-loaded with the action and outcome, and every word earns its place. The shorthand reference and scope requirement are valuable additions without any fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (single required parameter, no output schema, no annotations), the description is complete. It explains the purpose, the effect, the scope, and its relation to a sibling tool, giving an agent sufficient context to invoke it correctly and know what to expect.

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

  Parameters3/5

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

  The schema fully describes the only parameter (id) as 'PocketBase record ID of the post to unpublish,' giving 100% coverage. The description adds no additional parameter-level detail beyond confirming it's the post whose status changes. Baseline of 3 is appropriate since the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action ('Sets a post's status back to draft') and its effect ('taking it off the public site'). It distinguishes itself from the sibling update_post by identifying itself as a shorthand for a specific update_post call, making the purpose unmistakable even among similar tools.

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

  Usage Guidelines5/5

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

  Explicitly frames the tool as shorthand for update_post({ status: 'draft' }), which tells the agent when to use this tool versus the more general update_post. It also states the required posts:write scope, providing a clear prerequisite. No exclusions are needed for such a simple operation.

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