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

With no annotations, the description carries the full burden; it usefully discloses that the result is a Ghost-hosted URL, which is the key behavioral fact. It says nothing about auth requirements, size/format limits, what happens if the remote fetch fails, or that the upload creates a persistent asset on the Ghost instance.

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

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

Two tight sentences, front-loaded with the action and followed by the return value. No filler or repetition of schema fields beyond what is needed for orientation.

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

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

With no output schema, the description compensates by naming the return value (Ghost-hosted URL) and its intended use. It falls short only on the fact that neither parameter is required but at least one must be supplied, and on failure behavior for unreachable URLs.

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

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

Schema description coverage is 100% and both parameters (url, file_path) are documented in the schema itself, so the baseline is 3. The description restates the two sources but adds no syntax, mutual-exclusivity, or precedence information beyond the schema.

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

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

States a specific verb and resource ('Upload an image to Ghost') plus the two accepted sources, so the agent immediately understands the operation. No sibling tool in the list touches images, so there is no ambiguity to resolve.

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

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

The mention that the returned URL is 'to use as feature_image or in post HTML' implies the workflow context (upload before creating/updating a post), but no explicit when-to-use or when-not-to-use guidance or alternatives are stated. Usage is inferable rather than spelled out.

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

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

With no annotations, the description carries the full burden. It usefully discloses that only summaries are returned and that pagination and NQL filtering are supported, but says nothing about permissions/auth needs, rate limits, ordering defaults, or what a page summary actually contains.

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

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

Two short sentences, front-loaded with the core purpose and followed by capability notes. No filler, though it is arguably under-specified rather than a model of precision.

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

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

For a browse tool with full schema coverage and no output schema, the description covers the essentials but omits response-shape hints beyond 'summaries', sibling routing, and any behavioral constraints. Adequate minimum, with clear gaps.

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

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

Schema description coverage is 100%, so the baseline is 3. The description references pagination and NQL filtering, which maps to page/limit/filter, but adds no syntax or semantics beyond what the schema already documents (order parameter is not mentioned at all).

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

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

States a specific verb and resource ('List pages') and adds the scoping qualifier '(summaries only)', which meaningfully separates it from a full-content read. It stops short of naming the sibling it excludes (pages_read) or contrasting with posts_browse, so an agent must infer the distinction.

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

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

'summaries only' implies this is the lightweight listing counterpart to pages_read, but the description never states when to use it versus pages_read or posts_browse. Usage is inferable, not explicit.

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

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

With no annotations, the description carries full behavioral burden. It does disclose a genuine default not present in the schema (status defaults to draft), which is real added value. However, for a mutation tool it omits auth/permission requirements, what the response contains, and whether HTML conversion has side effects.

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

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

Two short, front-loaded sentences with no filler. It is appropriately sized as a sentence, though the brevity masks the under-specification addressed in other dimensions.

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

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

An 18-parameter mutation tool with no annotations and no output schema demands substantially more than two sentences. The description leaves publish/schedule semantics, ordering with feature_image uploads, and most field meanings undocumented.

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

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

Schema description coverage is only 39% across 18 parameters, so the description needs to compensate and does not — it mentions no fields other than the implied status. Uncovered parameters like featured, og_title, twitter_title, and codeinjection_* get no explanation anywhere.

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

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

States a specific verb and resource ('Create a page'), which is clear and distinct from posts_create/pages_update at the resource level. It doesn't explicitly contrast itself with the sibling posts_create, but the page-vs-post distinction is well established by the naming.

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

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

There is no guidance on when to use this versus posts_create, when to prefer tags/images_upload first, or what prerequisites exist. The only contextual hint is the draft default, which is about behavior rather than tool selection.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the single most important trait — that deletion is permanent and irreversible — but says nothing about required permissions, whether related resources are affected, or what the response returns.

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

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

Two short sentences, zero filler, with the destructive nature front-loaded after the core action. Nothing could be removed without losing meaning.

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

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

For a one-parameter delete tool with no output schema, warnings about irreversibility are the essential content and they are present. However, with no annotations and no sibling guidance, it leaves gaps around permissions and side effects that an agent authorizing a destructive call would benefit from.

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

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

Schema coverage is 0%, but there is only one parameter and the description clarifies it takes a page id. That is enough to call the tool, though it adds no format, validation, or accepted-value detail beyond the schema's 'string' type.

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

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

States a specific verb (delete) and resource (page) plus the identifier used, so an agent immediately knows what it does. It does not explicitly differentiate itself from the closely named siblings posts_delete or tags_delete, relying on the resource noun to do that work.

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

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

There is no guidance on when to use this tool versus alternatives such as pages_update (to modify rather than remove) or pages_browse. The only implicit signal is the word 'Permanently', which hints it is not a soft-delete path, but no alternative is named.

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

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

No annotations exist, so the description carries the full behavioral burden. It usefully discloses that the response includes the 'full HTML body' (a payload-size-relevant fact), but says nothing about authentication, error behavior for unknown ids/slugs, or rate limits.

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

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

A single sentence that names the verb, the resource, both lookup keys, and the notable return content. Zero filler and fully front-loaded.

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

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

No output schema, but the description explicitly notes the full HTML body is returned, covering the main return-value question. An agent could call this correctly; only error/edge-case behavior is left unstated.

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

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

Schema description coverage is 100% and both params (id, slug) are documented there, including the 'used when id is not given' precedence rule. The description only echoes 'by id or slug', adding no meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource ('Read a single page') and pins the scope to one record, which implicitly separates it from pages_browse. It does not name a sibling tool explicitly, so differentiation from pages_browse/posts_read is inferred rather than stated.

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

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

Usage is only implied: 'by id or slug' signals the two lookup paths but there is no statement of when to prefer this over pages_browse or what happens on a missing page. Adequate but thin.

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

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

With no annotations, the description carries the full burden, but it does disclose two genuinely non-obvious behaviors: partial-update semantics (only provided fields change) and automatic handling of Ghost's updated_at collision check. It omits auth/permission needs, whether unpublished-to-published transitions have side effects, and what the response looks like for a mutation tool.

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

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

Three short sentences, zero filler, with the core update semantics front-loaded ahead of the two behavioral caveats. Every sentence earns its place.

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

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

For a 19-parameter mutation tool with no annotations, no output schema and low schema coverage, the description is too thin — it explains partial-update behavior but leaves most parameters, permission requirements, and validation constraints unaddressed.

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

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

Schema description coverage is only 32% across 19 parameters, so the description must compensate and largely does not. It clarifies one parameter's semantics ('the body is replaced only when html is given'), but the other undocumented fields (og_title, twitter_title, custom_excerpt, featured, etc.) get no added meaning beyond the schema.

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

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

States a specific verb+resource ('Update a page'), which is unambiguous against siblings like pages_create, pages_delete, pages_read and pages_browse. However, it does not explicitly differentiate itself from those siblings beyond the verb, so it stops short of a 5.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives (e.g. when to reach for pages_create vs pages_update). The partial-update note describes mechanics, not when this tool should be selected over its siblings.

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

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

No annotations are provided, so the description carries the full burden. It does disclose a meaningful trait beyond the schema — results are summaries, not full post bodies — and notes pagination support. However, it says nothing about auth requirements, whether a total count is returned, or default result-set size.

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

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

Two short sentences, front-loaded with the core action and scope, with zero filler. Every clause carries information.

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

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

For a simple read-only list tool with a fully documented schema, the description covers what the tool returns (summaries) and what it supports (filters, pagination). With no annotations and no output schema, additional context on auth needs, default page size, or result shape would have helped, so it is adequate but not complete.

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

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

Schema description coverage is 100%, so all four parameters are already documented with defaults, bounds, and examples (NQL filter syntax, sort order format), which sets the baseline at 3. The description's mention of "Ghost NQL filters and pagination" loosely maps to filter/page/limit/order but adds no syntax or constraints beyond the schema.

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

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

States a specific verb and resource ("List posts") and adds a distinguishing scope note ("summaries only") that separates it from posts_read. It does not name the sibling it excludes, but the browse-vs-read distinction is inferable from the description alone.

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

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

Usage is implied rather than stated: "List posts (summaries only)" suggests this is for enumerating posts, and the summary qualifier hints at the posts_read alternative. There is no explicit when-to-use, when-not-to-use, or named alternative, and no mention of pagination defaults or ordering behavior.

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

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

With no annotations, the description carries the full burden. It does disclose one genuine behavioral trait not present in the schema: the post defaults to draft unless status is explicitly set. It omits auth requirements, side effects (e.g., Ghost auto-creating missing tags), and whether the newly created post is returned.

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

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

Two short, front-loaded sentences with no filler, and the default behavior is stated second. It is efficient, though borderline terse for a tool with this many knobs.

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

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

An 18-parameter mutation tool with no annotations, no output schema, and low schema coverage demands more than two sentences. Missing permission requirements, tag auto-creation behavior, and return semantics leave the definition materially incomplete.

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

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

With 18 parameters and only 39% schema description coverage, the schema leaves many fields (featured, og_*, twitter_*, codeinjection_*, custom_excerpt) undocumented. The description adds meaning only for status defaulting and says nothing about the other seventeen parameters.

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

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

States a specific verb+resource ('Create a post'), which cleanly separates it from posts_update, posts_read, and posts_delete. However it does not explicitly contrast with the adjacent pages_create sibling, so it stops short of full differentiation.

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

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

The only usage signal is the default-draft note; there is no guidance on when to choose posts_create over posts_update or pages_create, nor any prerequisite/permission context. An agent must infer usage entirely.

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

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

With no annotations, the description carries the full burden, and it does disclose the most important behavioral trait: the delete is permanent and irreversible. However, it omits auth/permission requirements, whether related data (comments, tags) is cascaded, and any error behavior, leaving substantial gaps for a destructive operation.

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

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

Two short sentences with zero filler; the destructive action is front-loaded and the irreversibility caveat follows immediately. Nothing needs trimming.

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

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

For a single-parameter destructive tool with no output schema, the core information (what it deletes, that it is permanent) is present. Minor omissions remain around permissions and side effects, but an agent has enough to invoke it correctly.

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

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

Only one parameter exists and schema description coverage is 0%, so the description must compensate. Saying 'by id' confirms the identifier's role, but adds nothing about acceptable format (slug vs numeric vs UUID) or validation, so the gap is only partially closed.

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

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

States a specific verb (delete) and resource (post) plus the scoping key (id), which cleanly separates it from posts_browse, posts_read, and posts_update. It does not explicitly name a sibling or contrast itself with pages_delete, so it stops just short of a 5.

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

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

There is no when-to-use guidance and no alternative named (e.g., posts_update for edits). The irreversibility warning implies caution, but the description never states under what conditions this tool should be chosen over modifying or archiving a post.

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

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

With no annotations, the description carries the full burden, but it does disclose the notable output trait: the response includes the 'full HTML body' rather than a summary. It says nothing about not-found behavior, auth requirements, or whether the read has side effects, which leaves meaningful gaps for a read tool.

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

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

A single front-loaded sentence with no filler; every clause (identifier options, payload content) earns its place.

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

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

For a two-optional-parameter read tool with no output schema, the description covers the essential facts, including the return payload. It slightly under-specifies the edge case where neither id nor slug is supplied, but otherwise nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema already documents both id and slug, including that slug is used when id is absent. The description's 'by id or slug' adds no syntax or precedence detail beyond that, so the baseline 3 applies.

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

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

The description gives a specific verb ('Read') and resource ('a single post'), and the word 'single' implicitly separates it from list-oriented siblings like posts_browse. It does not explicitly name the sibling to use for listing, but the scope is unambiguous.

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

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

There is no explicit when-to-use guidance, no mention of when to prefer posts_browse or pages_read, and no stated prerequisites. The 'by id or slug' phrasing is about inputs, not about tool selection.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses patch semantics ('only the provided fields change'), the html-replaces-body nuance, and automatic handling of Ghost's updated_at collision check – genuine behavioral context. However, it says nothing about auth requirements, failure modes, or what happens to unlisted fields on conflict, so it is not complete for a mutation tool with zero annotation coverage.

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

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

Three short, front-loaded sentences with no filler. The most decision-relevant fact (partial update) immediately follows the purpose statement, and the collision-check note is a single compact clause.

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

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

Given a 19-parameter mutation tool with no annotations and no output schema, the description covers the update model but omits auth/permission context, side effects like tag auto-creation, and any error behavior beyond the collision check. Adequate but with clear gaps.

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

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

Schema description coverage is only 32% across 19 parameters, so the description must compensate and largely does not. It adds real meaning only for html (body replaced only when given); the other ~18 fields, including status enum values and tag-creation side effects, get no clarification.

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

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

States a specific verb+resource ('Update a post') and adds scope detail about partial updates. It implicitly distinguishes from pages_update by naming 'post', but never explicitly names an alternative sibling, so differentiation is inferential rather than stated.

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

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

No guidance on when to use this versus pages_update, posts_create, or posts_read. There are no prerequisites or exclusions stated; the agent must infer that this is the mutation path because the name says 'update'.

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

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

With no annotations provided, the description carries the full burden. The word 'Read' signals a non-mutating, safe operation, which is the key behavioral trait for this tool, and the enumerated return fields confirm it is informational. It says nothing about auth requirements, permissions, or whether the data is cached, but for a zero-parameter read of static site metadata the disclosed risk profile 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.

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

A single short sentence with the verb and returned fields front-loaded and no filler. Every word earns its place.

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

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

No output schema exists, so the description wisely lists the fields returned (title, url, version), which is exactly what an agent needs before calling it. Since there are no parameters or annotations, little else is required; only usage timing remains uncovered.

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

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

There are zero parameters and the schema is empty, so there is nothing for the description to disambiguate. The baseline for a parameterless tool applies.

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

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

States a specific verb and resource ('Read basic site information') and even enumerates the returned fields (title, url, version), so the agent knows exactly what this yields. It does not explicitly contrast with any sibling, though none of the siblings (tags/images/posts/pages CRUD) overlap with site metadata, so confusion risk is low.

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

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

The description offers no when-to-use or when-not-to-use guidance and names no alternatives. Usage can only be inferred from the name and verb, which is thin for a tool meant to be selected among 16 siblings.

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

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

No annotations are provided, so the description carries the full burden. It discloses that results include post counts, but says nothing about read-only semantics, result set size, pagination limits, or ordering defaults for what is clearly a listing operation.

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

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

A single front-loaded sentence with zero filler. Nothing is repeated or wasted.

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

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

With no annotations and no output schema, the description should at least hint at return shape and paging behavior; it only notes post counts. The schema fully covers parameters, so the gap is behavioral rather than parametric.

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

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

Schema coverage is 100%, so all four parameters (page, limit, order, filter) are already documented with defaults and examples. The description adds nothing about them, which is the correct baseline when the schema does the heavy lifting.

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

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

States a clear verb ('List') and resource ('tags') and even discloses the notable payload detail (post counts). It does not distinguish itself from siblings like tags_create/tags_delete, but the browse-versus-mutate distinction is unambiguous from the name and verb.

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

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

No guidance on when to use this versus tags_create/tags_update/tags_delete, nor when to prefer it over posts_browse-style alternatives. No mention of pagination behavior or prerequisites, leaving the agent to infer usage entirely.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. "Create a tag" says nothing about permissions, idempotency, duplicate handling, side effects, or what happens if the tag already exists, leaving the agent with no behavioral context.

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

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

The single short sentence is technically concise but under-specified rather than efficient. It lacks the information an agent needs for a five-parameter tool, so brevity here represents a gap rather than good structuring.

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

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

With five parameters, no annotations, no output schema, and 0% parameter coverage, the description is far too thin to support correct invocation. It omits all field semantics and any behavioral context an agent would need.

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

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

The tool has five parameters with 0% schema description coverage, and the description mentions none of them. It does not explain the required name, optional slug, meta fields, or description semantics, so it fails to compensate for the schema gap.

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

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

The description gives a clear verb and resource ("Create a tag"), which is distinct from sibling operations like tags_update and tags_delete. It does not, however, differentiate from tags_browse or explain what kind of tag or where it applies, so it is clear but minimal.

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

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

There is no guidance on when to use this tool versus tags_update, tags_browse, or other creation tools. The description does not state prerequisites, uniqueness constraints, or expected context.

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

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

With no annotations, the description carries the full disclosure burden. It usefully reveals one non-obvious behavior — the delete is non-cascading, leaving a post's other tags intact — but omits irreversibility, permission requirements, and behavior when the id does not exist.

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

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

Two short sentences with the core action front-loaded and the side-effect note second. Nothing is wasted and the destructive action is stated first.

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

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

For a one-parameter delete with no annotations and no output schema, the description is adequate but thin: it never states that the operation is permanent or what a success/failure looks like. The non-cascading note is the right kind of content, but more of it is needed.

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

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

Schema description coverage is 0% for the single required 'id' parameter. The description only says 'by id', which minimally identifies it as the tag identifier but adds no format, prefix, or validation detail to compensate for the empty schema.

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

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

States a specific verb (delete) and resource (tag) plus the keying parameter, so an agent can immediately tell it apart from tags_create, tags_update, and tags_browse. It does not name a sibling explicitly, but the delete semantics are unambiguous within the set.

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

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

Usage is only implied: the tool deletes a tag, so the reader infers it is for tag removal. There is no statement of when to prefer this over tags_update (e.g., removal from a post) or any prerequisite, so guidance is minimal but not misleading.

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

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

With no annotations, the description carries the full behavioral burden and discloses almost nothing about this mutation. It does not state whether update is partial or full-replace, what happens to omitted fields, whether slug/name collisions error, or whether missing ids fail — all material for a write tool.

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

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

A single front-loaded sentence with no filler, which is structurally clean. However, brevity here reflects under-specification rather than efficient communication, so it cannot score highly.

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

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

For a mutation tool with no annotations, no output schema, and six undocumented parameters, the description should do far more. It lacks everything needed to call the tool safely apart from the id, leaving the agent to guess at field semantics and failure behavior.

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

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

Six parameters with 0% schema description coverage, and the description only mentions 'id'. The five optional fields (name, slug, meta_title, description, meta_description) are unexplained in both schema and text, and the critical partial-vs-replace semantics of optional fields are left ambiguous.

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

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

It names a verb and resource ('Update a tag') and adds an identification hint ('by id'), so the operation is discernible. But it is nearly a restatement of the tool name and offers no differentiation from siblings like tags_create or tags_delete.

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

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

No guidance on when to use this rather than tags_create or tags_delete, no preconditions, and no note about how it relates to tags_browse for locating an id. Usage is entirely implied by the name.

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