Server Quality Checklist

Tool Scores

• delete_pageB
  3.3/5.0
  Behavior4/5

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

  Annotations already mark this as destructive, but the description adds the important behavioral warning that deletion should be treated as irreversible. This goes beyond the structured hint and helps the agent anticipate consequences, though it relies on delete_post for further detail.

  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 short sentences, front-loaded with the core action and followed by a relevant warning. Every word contributes, and there is no redundant or filler content.

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

  Completeness2/5

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

  The tool is relatively simple and has an output schema, but the description leaves the permanent parameter's behavior unexplained and delegates important nuance to delete_post. For a destructive operation, the absence of explicit guidance about the permanent flag is a meaningful gap.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not explain blog_id, page_id, or permanent. The permanent parameter is especially important because its default of false may imply a non-permanent delete, yet the description provides no clarification of how it interacts with the irreversibility warning.

  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 and resource: 'Delete a static page.' It clearly distinguishes this from the sibling delete_post by specifying 'static page', and the reference to delete_post further reinforces that this is the page-specific counterpart.

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

  Usage Guidelines2/5

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

  No explicit guidance about when to use this tool versus alternatives. The 'static page' wording implies the intended resource, but there is no mention of prerequisites, permissions, or exclusions such as 'use delete_post for posts instead.'

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

• update_pageB
  3.4/5.0
  Behavior4/5

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

  Annotations already signal readOnly=false and destructive=true, but the description adds important behavior: only passed fields are sent (PATCH semantics) and publish=True publishes a draft as part of the edit. This is valuable context that is not in the annotations and does not contradict them.

  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 tight sentences with no filler. The core operation is front-loaded, and the PATCH semantics and publish behavior are stated precisely.

  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 annotations, output schema, and clear sibling context, the description provides the key behavioral information an agent needs: PATCH semantics and publish behavior. It does not cover edge cases such as what happens when publishing a non-draft page, but for a simple update tool this is reasonably complete.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description should compensate for undocumented parameters. It only explains publish; title, content, content_format, blog_id, and page_id are left to inference from their names or the schema. This is insufficient for a 6-parameter tool.

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

  Purpose4/5

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

  The description clearly states the resource ('a static page') and the operation ('Update'), and adds useful PATCH semantics. It distinguishes from update_post via 'static page', though it does not explicitly contrast with create_page or delete_page.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives, such as create_page for new pages or update_post for posts. It also does not mention prerequisites or conditions that would make this tool the right choice.

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

• create_pageA
  3.8/5.0
  Behavior4/5

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

  The description goes beyond the annotations by stating that the page is created as a draft by default and by constraining allowed content to raw HTML or plain text, with no Markdown or image upload. This gives the agent practical behavioral expectations that annotations like readOnlyHint and openWorldHint do not convey.

  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 filler. The primary action is front-loaded, and the content-rule constraint is efficiently communicated by referencing create_post rather than repeating a long list.

  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 output schema covers return expectations, and the description covers the most important behavioral constraint: draft-by-default and content format rules. It does not explain where blog_id comes from or explicitly address the page-vs-post decision, but these are reasonably inferrable from the resource type and sibling tool names.

  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 0%, so the description must compensate for sparse parameter documentation. It adds meaningful guidance for content_format by forbidding Markdown and image upload, and it reinforces the draft parameter's default behavior. However, blog_id is left unexplained, and there is no explicit mapping of the described content rules to the actual parameter names.

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

  Purpose4/5

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

  The description clearly states the operation with 'Create a static page' and adds the key behavior that it creates a DRAFT by default. It does not explicitly distinguish create_page from the sibling create_post beyond the phrase 'static page' and a shared-content-rules reference, so it falls just short of full sibling differentiation.

  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 intended use case is implied by 'Create a static page,' and the draft-default behavior gives some context. However, the description never states when to choose create_page over create_post or other sibling tools, and the reference to create_post is only about content rules, not tool selection.

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

• list_commentsA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and access scope are covered. The description adds useful behavioral context: omitting post_id broadens the query to the entire blog, and status filters results. However, it does not disclose pagination behavior, ordering, or how many results are returned by default, even though page_token and max_results exist.

  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 filler. The main operation and scope are front-loaded, and the moderation example earns its place by showing a common use of the status parameter.

  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 core listing behavior and a usage case are covered, and the output schema exists so return values are documented elsewhere. However, the description leaves pagination unexplained: page_token and max_results are parameters an agent may need to use, and no guidance is given for paging through results. This is a meaningful gap for a list tool of this complexity.

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

  Parameters2/5

  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 meaning for post_id (optional, scope changes to whole blog) and status (PENDING example), but does not explain page_token, max_results, or blog_id. The enum values for status are in the schema, but the remaining parameters lack descriptive support in both schema and description.

  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 and resource: 'List comments', and immediately clarifies scope by saying it can target one post or the whole blog. This makes it clearly distinguishable from siblings like list_posts and list_pages, and the optional post_id behavior is called out explicitly.

  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?

  It provides a concrete, actionable use case: Use status="PENDING" to find comments waiting for moderation. It does not explicitly name alternatives or exclusions, but the resource and scope are clear enough that an agent can decide when to call this tool.

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

• list_pagesA
  3.8/5.0
  Behavior3/5

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

  The readOnlyHint and openWorldHint annotations already communicate the safe read-only nature, so the description does not need to repeat that. It adds domain context about pages, but does not disclose behavior such as default status filtering, pagination semantics, or ordering. This is acceptable for a simple list tool but not rich.

  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 short and front-loaded with the core purpose. The second sentence earns its place by clarifying what makes pages distinct from posts, without unnecessary fluff.

  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 presence of an output schema and annotations reduces the burden, and the description conveys the core domain difference. However, it does not explain optional parameter behavior or pagination, which would improve invocation correctness for this 5-parameter tool. It is adequate but has clear, fixable gaps.

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

  Parameters2/5

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

  With 0% schema description coverage across 5 parameters, the description needs to compensate, but it only implies blog_id through 'of a blog.' It does not explain the semantics of status, page_token, max_results, or fetch_bodies, leaving the agent dependent on schema names and defaults alone.

  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 and resource: 'List the static pages of a blog,' with clear examples. It also distinguishes pages from posts by domain characteristics, which helps the agent identify that list_pages is the right sibling for static content rather than list_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?

  It provides clear context by contrasting pages with posts ('no labels, no dates in the archive, not in the post feed'), which signals when pages are the target. It stops short of explicitly naming alternative tools or stating when not to use this tool, but the differentiation is enough for common selection cases.

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

• get_pageA
  3.9/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds behavioral context by stating the response includes the full HTML body and is returned 'in full', which is useful beyond the annotations. It does not list rate limits or access requirements, but this is mostly unnecessary for a simple read-only 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?

  The description is a single concise sentence that front-loads the core action. Every phrase earns its place: 'one' clarifies scope, 'static page' distinguishes from posts, and 'including its HTML body' adds concrete return-value context.

  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 tool is a simple two-parameter read-only fetch and an output schema exists, the description is nearly complete. The only notable gap is the lack of explicit parameter guidance and routing to list_pages for page discovery, but for the tool's low complexity this is a minor shortcoming.

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

  Parameters2/5

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

  Schema description coverage is 0% and the description provides no parameter details. The parameter names blog_id and page_id are somewhat self-descriptive and both are marked required, but the description does not explain their roles, formats, or how an agent should obtain valid values. With low schema coverage, the description needed to compensate and did not.

  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 ('Fetch'), names the resource ('one static page'), and adds valuable scope details ('in full', 'including its HTML body'). It is clearly distinguished from list_pages, get_post, and other siblings.

  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 use when an agent needs to retrieve a single static page by ID, but it does not explicitly mention alternatives or when not to use it. An agent can infer list_pages is for listing and get_post is for posts, but the guidance is implicit rather than direct.

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

• list_postsA
  3.9/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint and openWorldHint, and the description adds meaningful behavior beyond them: bodies are omitted by default, and fetching them is expensive. This helps the agent avoid an inefficient call without contradicting the annotations.

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

  Conciseness5/5

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

  The description is compact, front-loaded with the core action, and uses code-formatted parameter notes efficiently. Every sentence provides actionable information, including the performance rationale for fetch_bodies.

  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 description covers the most important filter and payload behavior, and an output schema may cover return shape. But it does not explain pagination, ordering, or whether date filters apply to PUBLISHED or UPDATED, which are material for a list tool with 10 parameters.

  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 description usefully explains status values, label format, date format, and fetch_bodies semantics. However, with schema description coverage at 0%, several parameters remain unexplained, such as pagination (page_token/max_results) and sort/order_by semantics, leaving meaningful gaps.

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

  Purpose4/5

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

  The description states a clear verb and resource: 'List posts in a blog.' It is distinct from list_blogs/list_pages by resource and from get_post by plurality, but it does not explicitly differentiate itself from search_posts or other siblings.

  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 gives concrete usage context: status can be omitted for all, and fetch_bodies should only be passed when the HTML is actually needed because bodies are large. It does not explicitly say when to prefer search_posts or other alternatives, so it stops short of 5.

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

• get_postA
  4.1/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=true, and the description is consistent with that. It adds useful behavioral context by noting that the full post content, including HTML body and sync metadata, is returned, and that it provides the current content for safe edits.

  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-loads the core purpose, and uses the second sentence to provide a valuable usage directive. Every sentence 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 simple read tool with an output schema and read-only annotations, the description covers purpose, return contents, and a key call-order constraint. Minor gaps include explicit parameter documentation and alternative-tool routing, but the overall definition is sufficiently complete for correct selection and invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description carries the burden of explaining parameters, but it does not mention blog_id or post_id at all. The parameter names are relatively self-explanatory, yet the description adds no semantic meaning beyond the 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 states a specific verb ('Fetch'), a precise resource ('one post'), and key output details ('HTML body and sync metadata'). This clearly distinguishes it from sibling list/search tools and leaves no ambiguity about what the tool retrieves.

  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 gives an explicit usage instruction: 'Always call this before update_post' to avoid editing stale content. It does not explicitly mention alternatives or when not to use it, but the usage context is clear and actionable.

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

• get_blogA
  4.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint and openWorldHint, covering the safety profile. The description adds the constraint that exactly one identifier must be passed and that the URL must be public, but it does not describe result behavior such as not-found handling or redirection.

  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 short sentences: the first states purpose, the second gives the critical invocation rule. No filler or redundant repetition of schema details.

  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, an output schema, and read-only annotations, the description is nearly sufficient. It could add a pointer to list_blogs for enumeration or mention not-found behavior, but these are minor gaps.

  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?

  Input schema has no descriptions, so the description carries the burden. It names both parameters, explains their roles (id vs public URL), imposes mutual exclusivity, and gives a concrete URL format. It does not clarify the blog_id format beyond 'id'.

  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?

  States a specific verb ('Look up') and resource ('one blog'), and identifies the two valid identifiers (id, public URL). It is clearly distinct from sibling list/get tools targeting different resources or collections.

  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 explicit invocation guidance: pass exactly one of blog_id or url, with an example URL. It does not explicitly name alternatives or when-not-to-use, but the lookup semantics make the use case clear.

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

• get_pageviewsA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, but the description adds meaningful behavioral context beyond that: the data is coarse, approximate, and not a precise analytics signal. It discloses inherent limitations without contradicting the annotations.

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

  Conciseness5/5

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

  The description is two short paragraphs: one clear purpose statement and one concise caveat paragraph. Every sentence adds value, with the most important information front-loaded.

  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?

  With an output schema present, return values need no explanation. The description covers the key caveats (approximation, no per-post breakdown) and makes the tool's limitations clear. It is complete for a simple two-parameter read-only tool.

  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 0%, so the description must compensate. It partially does by referencing 'three coarse buckets' (matching the time_range enum) and 'Blog-level' (implying blog_id), but it doesn't explicitly describe each parameter. The schema names and enum values carry most of the parameter semantics.

  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 'Blog-level pageview counts' with a specific verb and resource, and is clearly distinguished from all sibling tools, which focus on blogs, posts, pages, and comments — none of which cover pageview analytics. The additional 'no per-post breakdown' clarifies the exact 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?

  The description provides clear context about what the tool returns and its limitations ('approximate', 'rough signal not analytics', 'no per-post breakdown'), which implicitly tells an agent when not to use it. No alternative pageview tool exists among siblings, so explicit exclusions are unnecessary.

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

• search_postsA
  4.2/5.0
  Behavior4/5

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

  The description discloses an important behavioral boundary beyond annotations: only live/published posts are indexed and drafts are excluded. This adds meaningful context beyond readOnlyHint and openWorldHint, and there is no contradiction with annotations.

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

  Conciseness5/5

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

  Two short, information-dense sentences. The first states what the tool does, and the second immediately provides the critical exclusion and alternative. There is no filler or redundant wording.

  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 scope and draft-handling guidance are strong, and the output schema reduces the need to describe return values. However, the bare input schema and lack of parameter explanation for fetch_bodies and query leave meaningful gaps for correct invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description needed to explain blog_id, query, and fetch_bodies. 'Full-text search' hints at the meaning of query, but blog_id and fetch_bodies receive no semantic explanation, leaving an agent to infer their roles from names and types alone.

  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 clear verb and resource: 'Full-text search over the published posts of a blog.' It also differentiates itself from list_posts by explicitly noting drafts are not indexed and pointing to the alternative, so an agent can distinguish sibling tools confidently.

  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?

  The description explicitly says when not to use it: drafts are not covered. It then names the alternative, list_posts with status="DRAFT", providing clear routing between search_posts and list_posts.

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

• revert_postA
  4.3/5.0
  Behavior4/5

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

  Annotations already indicate a non-readonly, non-destructive, idempotent operation. The description adds valuable behavior context: content is preserved, only visibility changes, and this is the safe way to remove a post. No contradiction with annotations.

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

  Conciseness5/5

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

  Three short sentences with no filler. The action is front-loaded, the non-destructive nature is explained, and the safe-use framing earns its place. Every sentence contributes to correct tool selection and invocation.

  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 simple two-parameter tool with an output schema and safety-relevant annotations, the description is complete. It covers eligible states, the effect, and the safety profile, so an agent has enough context to call the tool correctly.

  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 input schema provides no property descriptions, so coverage is low. However, blog_id and post_id are self-explanatory identifiers, and the description references posts and blogs, giving enough context. The description does not explicitly map parameters or explain their format, so it adds little beyond the 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?

  States a specific verb and resource: taking a live or scheduled post back to DRAFT. It clarifies that the post is removed from the blog while content is kept, and positions this as the safe alternative to deletion, distinguishing it from delete_post and publish_post.

  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 usage context: use for live or scheduled posts that need to be pulled down without destroying content. It implies that delete_post is the destructive alternative, but it does not explicitly name alternatives or 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.

• moderate_commentA
  4.4/5.0
  Behavior5/5

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

  The description adds meaningful behavioral detail beyond the annotations: 'delete' is NOT recoverable, 'approve' also un-spams, 'remove_content' leaves a stub, and 'spam' hides the comment. These disclosures complement the destructiveHint and help the agent understand consequences of each action.

  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 compact, front-loaded with the core purpose, and uses a clear bulleted list for each action. Every sentence contributes either action semantics or a critical caveat, with no 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 four-parameter moderation tool with an output schema, the description covers the action semantics, irreversible consequences, and a key API limitation. It does not explain how to obtain comment IDs or mention list_comments, but those are reasonably inferable from the parameter names and sibling tools.

  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 description thoroughly explains the 'action' enum values, which is the parameter that most needs semantic clarification. However, blog_id, post_id, and comment_id receive no description-level elaboration; their semantics are only inferable from their names and schema titles. Given 0% schema description coverage, this is partial but not complete compensation.

  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 the specific operation—'Moderate one comment'—and enumerates the four distinct moderation actions with concrete effects. This clearly distinguishes it from sibling tools like list_comments and the broader blog/post management tools.

  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 action list explicitly explains when to choose each behavior, including a warning to confirm with a human before using 'delete'. It also explicitly notes that the Blogger API cannot create comments, so replying must be done manually—an exclusion that prevents misuse.

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

• delete_postA
  4.7/5.0
  Behavior5/5

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

  Annotations already mark this as destructive and not read-only, but the description adds critical context: deletion is irreversible from the API's perspective, deleted posts return 404, never appear in SOFT_TRASHED listings, and the API cannot tell whether Blogger's UI can restore them. This goes well beyond the structured hints and does not contradict them.

  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 compact and well-organsed: the core warning comes first, followed by useful operational nuance, then the sibling alternative. Every sentence earns its place; there is no padding or repetition.

  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 destructive tool with no parameter descriptions in the schema, this covers the essential decision factors: human confirmation, irreversibility, observable 404/list behavior, and the safer alternative. Since an output schema exists, not describing return values is acceptable. No critical guidance is 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?

  Schema coverage is 0%, so the description must compensate for missing parameter documentation. It does clarify the `permanent` parameter by explaining that `useTrash` is sent unless `permanent=True` and that the distinction has no observable API effect. `blog_id` and `post_id` are self-explanatory from their names, but value formats or edge-case behavior are not fully specified.

  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 opens with a specific verb and resource: 'Delete a post.' It is unambiguous about what the tool does and later contrasts itself with `revert_post`, so an agent can distinguish irreversible deletion from a reversible unpublish.

  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?

  The description explicitly says to confirm with a human before invoking, and directly names `revert_post` as the better alternative when the goal is to take a post off the public blog. This gives 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.

• list_blogsA
  4.7/5.0
  Behavior4/5

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

  The annotations already declare readOnlyHint and openWorldHint, so the description is not required to restate safety. It adds meaningful context about the authorized account scope and the discovery workflow, going slightly beyond the annotations without contradicting them.

  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 fully convey purpose and usage context. The main action is front-loaded, and every sentence adds value with no 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?

  For a zero-parameter, read-only tool with an output schema and helpful annotations, the description is complete. It states what the tool returns conceptually (accessible blogs), when to invoke it, and how it fits among sibling tools.

  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?

  The tool has zero parameters, so the baseline is 4. The description properly focuses on the tool's purpose and result rather than inventing parameter details that do not exist.

  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 identifies the action ('List the blogs the authorized Google account can access') and the resource (blogs). It also explicitly explains the tool's role in discovering a blog_id, which distinguishes it from all sibling tools that require blog_id as input.

  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?

  The description explicitly states when to use the tool: when you do not already have a blog_id. It reinforces the decision by noting every other tool requires the caller to pass blog_id explicitly, effectively routing the agent to use this tool first.

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

• publish_postA
  4.9/5.0
  Behavior5/5

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

  Annotations already mark this as a non-read-only, non-destructive operation, so the description adds valuable context: it is described as 'irreversible-feeling,' it makes the post publicly visible, and future-dated publication leaves the post in SCHEDULED status. This complements the annotations without contradicting them.

  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 compact and front-loaded: action first, human-confirmation caution second, scheduling detail third. Every sentence earns its place, and the RFC 3339 example is concrete and useful.

  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 mutating publish tool with an output schema present, the description covers the preconditions (draft), the need for human confirmation, immediate vs. scheduled publishing behavior, and the resulting status. An agent has enough information to select and invoke the tool correctly.

  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?

  Schema description coverage is 0%, so the description carries the burden for parameter meaning. It thoroughly explains publish_date with RFC 3339 format, scheduling semantics, and resulting status. The blog_id and post_id are left implicit, but their names make them self-explanatory as identifiers.

  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?

  Description opens with a specific verb and object: 'Publish a draft post,' and states the explicit outcome ('making it publicly visible'). This clearly separates it from siblings like update_post or revert_post, which modify content rather than changing visibility state.

  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?

  Provides explicit decision guidance: confirm with the human before calling unless publication was already requested, and use publish_date for scheduling instead of immediate publication. This tells an agent exactly when to invoke the tool and when to pause.

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

• update_postA
  4.9/5.0
  Behavior5/5

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

  Annotations declare the operation is mutating and destructive, and the description adds crucial behavior beyond that: omitted fields are untouched, labels are wholesale-replaced, and publish=False has no unpublish effect. No contradiction with annotations.

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

  Conciseness5/5

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

  The key semantic is front-loaded in one sentence, followed by two tightly scoped bullets that address the highest-risk behaviors. No filler and no repetition of schema field names.

  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 an 8-param mutation with an output schema, this description provides the PATCH contract, the two surprising behaviors (labels replace, publish default), and the alternative tool for reverting live posts. Nothing needed to call it safely is 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?

  With 0% schema description coverage, the description compensates by teaching PATCH semantics across all params and calling out the dangerous label-replacement and publish-default behavior. It uses title/body examples but does not explain reader_comments or content_format nuances, though their schema enum/defaults make those largely inferable.

  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?

  Description leads with 'Update a post, sending only the fields you pass (PATCH semantics)', naming the precise verb and resource, and distinguishes it from siblings like publish_post, revert_post, and create_post through the bullets.

  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 tells agents when PATCH semantics matter, and routes them to get_post before label replacement and to revert_post for unpublishing, and clarifies publish=False does not unpublish. This is clear when-to-use vs alternative guidance.

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

• create_postA
  5/5.0
  Behavior5/5

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

  Annotations only indicate non-read-only and non-destructive behavior, so the description carries the burden of explaining effects. It discloses the default draft state, exact content_format handling (raw HTML vs escaped text), the lack of Markdown and image upload, and the silent discarding of customMetaData. These are behavioral traits well beyond what the annotations provide, with no contradiction.

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

  Conciseness5/5

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

  Every sentence earns its place. The core purpose is front-loaded, and the description uses short paragraphs to cover publishing flow, content formatting, and important Blogger limitations without fluff or repetition.

  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 has 7 parameters, several subtle behaviors, and a sibling workflow (publish_post), the description is complete: it covers the default draft, how to publish, content format semantics, unsupported features, and metadata limitations. The output schema exists, so the agent can learn return shape elsewhere. Nothing essential for correct invocation is missing.

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

  Parameters5/5

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

  Schema description coverage is 0%, but the description compensates for the non-obvious parameters: draft is explained as a default true with explicit publication guidance, and content_format is fully specified ('html' passes content untouched; 'text' escapes and wraps in paragraphs). It also clarifies constraints on content (no Markdown, no image upload, img must be absolute public URL). Remaining parameters like blog_id, title, labels, and reader_comments are self-evident from the 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 opens with 'Create a post' — a specific verb and resource — and immediately clarifies that it creates a DRAFT by default. This distinguishes it from publishing-related siblings like publish_post and from update_post. The purpose is unambiguous.

  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?

  The description gives explicit usage guidance: publishing is a separate step via publish_post, and draft=False should only be used when a human has explicitly requested immediate publication. It also warns that Markdown and image upload are unsupported, helping an agent choose appropriate content. This is clear when-to-use and when-not-to-use guidance.

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