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

No annotations are provided, so the description carries the full behavioral burden for a mutation tool. It says nothing about permissions/auth, name uniqueness or collisions, idempotency, or what happens on failure, so the safety profile is entirely opaque.

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 action and followed by the definition. No filler, though the second sentence largely duplicates the permalink schema description rather than earning new 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?

With no annotations and no output schema, an agent gets no picture of what is returned (e.g. an id) or what authorization/cloning behavior to expect. The parameter layer is well covered by the schema, but the create lifecycle remains under-described.

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 83%, so the schema already documents nearly every parameter (including the navigation/footer/signature convention for permalink). The description restates the site-wide-versus-reusable distinction the schema already carries, adding little new parameter meaning, so baseline 3 applies.

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

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

States a specific verb and resource ('Create a component') and adds a definition of what a component is versus other content. It does not explicitly contrast with sibling create tools like create_page or create_post, but the site-wide/reusable framing makes the resource distinct.

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 definition of components (site-wide parts vs reusable blocks) implies when the tool applies, but there is no explicit when-to-use guidance, no exclusion of create_page/create_post, and no prerequisites. Usage is inferable only from the noun definition.

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 behavioral burden. It implies a mutation and hints at the effect (a bookable type appearing in the booking block), but says nothing about permissions, whether 'enabled' defaults to true/false, or what happens if a type with the same name exists.

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 tight sentence with the core action front-loaded and no filler. It is appropriately sized, though it is arguably too terse for the parameter surface it governs.

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 5 parameters, 3 required, no output schema, and no annotations, the description should at minimum state required fields, the format of 'length' beyond the schema, or default behavior for 'enabled'. It provides none of this, so the definition is thin relative to the tool's complexity.

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

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

Schema description coverage is only 40% – only 'cost' and 'length' carry inline descriptions, while 'name', 'enabled', and 'description' are undocumented. The description adds no parameter-level meaning at all, so it fails to compensate for the coverage gap on a 5-parameter tool.

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 bookable meeting type') and adds a useful qualifier about where it surfaces ('shown in the booking block'). However, it does nothing to distinguish itself from the sibling update_meeting_type/delete_meeting_type beyond the verb, leaving sibling differentiation implicit.

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 when-to-use guidance, no prerequisites, and no mention of the sibling update_meeting_type for modifying an existing type. The agent is left to infer that this is the creation path versus the update path from the name alone.

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. It discloses genuine traits: the permalink maps to the public URL path, must be unique, and has reserved values that cause rejection. It is silent on permissions/auth requirements, whether the page is immediately live, and what a failed creation 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 tight sentences: the operation first, then the only non-obvious constraint (permalink behavior and reserved values). No filler, no repetition of the name, and the most failure-prone rule is placed adjacent to the action statement.

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 10-parameter mutation tool with no annotations and no output schema, the description covers only permalink semantics. It omits auth/permission needs, the default archival/publish state, and any indication of what the caller receives on success, leaving notable gaps for an agent invoking a write operation.

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 already 80%, so the baseline is 3. The description meaningfully elaborates only one of ten parameters (permalink), adding the reserved-path rule that the schema does not state; the other nine parameters, including required 'name', receive no extra interpretation.

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'), so the operation is unambiguous. However, it offers no differentiation from structurally similar siblings such as create_post, create_component, or create_redirect, leaving the agent to infer that this tool is specifically for pages.

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 reserved-path rule ('shop, post, events, donate are rejected') implicitly tells the agent when a permalink choice will fail, which is useful constraint guidance. But there is no explicit statement of when to reach for this tool versus its siblings, and no prerequisites or preconditions are given.

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 a behavioral trait the schema does not (the draft default, since the 'draft' property has no schema description or default), but says nothing about permissions, what publishing does, validation limits, or error behavior.

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

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

Two short, front-loaded sentences with no wasted words. The phrasing 'Defaults to draft unless draft=false' is a slightly awkward double negative, but it is efficient and readable.

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 an 8-parameter mutation tool with no annotations and no output schema, this is thin. Nothing is said about what the created post looks like on return, what happens on validation failure, how the permalink is derived, or what permissions are required.

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 only 25% (body and date described), and the description only adds meaning for one parameter, 'draft'. Six of eight parameters — title, tags, subtitle, permalink, read_time, date — receive no clarifying semantics beyond their bare JSON-Schema types.

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

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

States a specific verb and resource: 'Create a blog post.' An agent can identify the operation immediately. It does not, however, differentiate itself from the closely named siblings create_page/update_post, so it stops short of 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?

The draft-default note gives an implied workflow hint (create posts unpublished unless overridden), but there is no explicit when-to-use guidance versus update_post or create_page, and no stated prerequisites or publish path.

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. It does disclose two non-obvious traits: the operation is an upsert ('create or replace') and redirects are evaluated before page lookup. It does not mention permissions, validation of the source path, or how conflicts with existing pages/redirects are resolved.

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, front-loaded with the core action and followed by two facts that each change agent behavior (evaluation precedence, default status code). No filler or restatement of the tool name.

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 and no output schema, the description covers the essentials: what it does, upsert behavior, precedence, and the status-code default. It stops short of describing permissions, conflict handling, or the shape of a successful result, which leaves meaningful gaps for a write operation.

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 only 33% — only to_permalink is documented. The description compensates partially by framing the parameters as 'from one path to another' and by documenting the http_code default (301) and allowed values (302), which the enum alone does not convey. from_permalink format and constraints remain unexplained in both places.

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 pair and resource ('Create or replace a redirect from one path to another'), which is more precise than the name alone because it signals upsert semantics. It does not explicitly name the sibling alternatives (delete_redirect, list_redirects), though the create action is unambiguous. Clear enough that an agent can distinguish it from the other redirect tools.

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

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

'Checked before page lookup' gives implied context about when a redirect takes effect relative to page resolution, which is genuinely useful routing context. However, there is no explicit when-to-use vs. when-not guidance (e.g., relationship to create_page, or what happens if a redirect already exists). Usage is inferable but not stated.

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 it does disclose one important trait: the delete is 'soft', implying the record is not permanently destroyed. It omits what state the component ends up in, whether it can be restored, idempotency on repeat calls, and any permission requirements.

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 six-word sentence with the action and its scoping constraint front-loaded and zero filler. Nothing is padded or redundant.

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 mutation with a complete schema and no output schema, the description is minimally sufficient. It leaves open the practical consequences of a soft-delete (recoverability, visibility of the deleted component), which matter for a destructive operation with no annotations.

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% and the single parameter is fully documented in the schema, so the baseline of 3 applies. 'By id' in the description adds only a restatement of the schema's id property.

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 ('soft-delete') and resource ('component by id'), which cleanly distinguishes it from delete_page, delete_media, and delete_redirect in the sibling list. It does not, however, explicitly contrast itself with update_component or explain how soft-delete differs operationally, so it stops 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.

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

There is no when-to-use guidance, no note on whether the soft-deleted component can be restored, and no pointer to an alternative such as update_component for non-destructive edits. The agent must infer usage entirely from the tool name.

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

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

No annotations provided, so the description carries the burden; it discloses a real side effect (broken assets on pages referencing the URL), which is valuable beyond structured fields, though it doesn't mention irreversibility or permissions.

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 action and followed by the key consequence; no wasted words.

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

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

For a single-param destructive tool with no output schema, the description covers the core action and a major side effect, but omits whether the deletion is permanent/reversible or requires permissions.

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 the schema already documents the id parameter; the description adds no syntax or format details beyond repeating 'by id'.

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 'a media item by id', clearly distinguishing it from siblings like upload_media and list_media.

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?

Implied usage from the verb and resource, but no explicit when/when-not or alternatives (e.g., no mention of deleting vs. replacing media).

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 it does disclose one important trait: the precondition of zero bookings and the fallback of disabling instead. However, it says nothing about required permissions, whether the delete is reversible, or what happens if the precondition is violated.

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 front-loads the action and appends the gating condition. No filler words, nothing redundant.

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 annotations and no output schema, the description covers the critical decision point (bookings vs. no bookings). It is nearly complete, missing only permission/auth expectations and error 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?

Schema coverage is 100% and there is only one parameter, so the schema already documents 'id' as a positive numeric identifier. The description adds no format or semantic detail beyond that, so the baseline of 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 states a specific verb (delete) and resource (meeting type) and adds the scope constraint (no bookings), which cleanly separates it from siblings create_meeting_type and update_meeting_type. An agent can identify the tool's job without opening the schema.

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

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

It gives explicit use criteria: delete when there are no bookings, otherwise disable. That is a clear when/when-not condition. It stops short of naming the alternative tool (update_meeting_type) that performs the disable, leaving the routing to inference.

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 'soft-delete' is a genuinely useful disclosure: the record is marked rather than destroyed, implying recoverability. However it omits permissions, whether child components/redirects are affected, and whether a restore path exists, so it covers only one behavioral trait of a mutation 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 four-word sentence with the verb, the critical 'soft' qualifier, and the identifying parameter front-loaded. Zero filler; nothing could be trimmed without losing 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 destructive-adjacent operation with no annotations and no output schema, an agent still lacks side-effect information (cascade to components/redirects), confirmation behavior, and recovery options. The schema is simple and fully documented, so this is adequate but has 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?

Only one parameter and schema description coverage is 100%, so the schema already fully documents 'id' (numeric, exclusiveMinimum 0). The phrase 'by id' adds no meaning beyond that, making the baseline 3 correct.

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?

Specific verb+resource ('soft-delete a page by id') that cleanly separates it from the sibling mutation tools (update_page, create_page) and from delete_component. It is clear what the tool acts on, though it does not name any sibling or scope contrast explicitly.

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 when-to-use, when-not-to-use, prerequisites, or alternative tools are given. The 'soft' qualifier hints at behavior but gives no guidance on when this is preferred over update_page or how it relates to list_pages/get_page.

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 bears the full disclosure burden for a destructive operation. It does not say whether deletion is permanent or reversible, whether it requires elevated permissions, or what happens on a non-existent id — all critical for a delete 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 short sentence with the operation and identifier front-loaded and zero filler. It is appropriately sized for a one-parameter tool, though that brevity partly reflects missing detail rather than tight editing.

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 trivial single-param tool with a fully documented schema and no output schema, the description is minimally sufficient to invoke it correctly. However, with no annotations, the absence of any statement about irreversibility or failure behavior leaves a real gap for a destructive operation.

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 the single 'id' parameter is documented as a positive numeric id, so the schema does the heavy lifting. 'By id' in the description merely echoes the parameter name without adding format or lookup guidance.

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 ('a redirect') with the keying parameter ('by id'), which cleanly separates it from list_redirects and create_redirect. It stops short of explicitly contrasting with siblings, but the operation 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 guidance on when to use this versus alternatives, no preconditions (e.g., whether the redirect must exist or be inactive), and no mention of the sibling operations for redirects. The agent is left to infer everything from the name.

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 behavioral burden. 'Get' implies a read operation and the field list conveys the returned content, but there is no disclosure of auth/permission requirements, side effects, or pagination behavior.

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

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

A single front-loaded sentence that lists the setup components without any filler. Every phrase contributes to identifying the resource and its contents.

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 zero-parameter getter with no output schema, the description enumerates the main booking setup components (timezone, notice period, booking window, buffers, weekly hours, meeting types), which is largely sufficient. It omits return structure details, but not severely.

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 zero parameters, so the baseline per rubric is 4. The description lists returned fields rather than input parameters, and the empty schema confirms no input semantics to explain.

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 uses a specific verb ('Get') and resource ('booking block setup') and enumerates the setup fields returned. It does not explicitly contrast with the sibling update_booking_setup, but the read nature is clear from the 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?

There is no explicit when-to-use guidance, prerequisites, or mention of alternatives such as update_booking_setup. Usage is only inferable from the verb 'Get'.

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 burden. It usefully discloses that the return contains full html, css and js (as opposed to metadata only), but says nothing about read-only nature, permissions, or not-found behavior. It adds some behavioral context but leaves clear gaps.

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 core purpose front-loaded before the parameter hint. Nothing is 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?

For a simple two-parameter getter with full schema coverage, the description covers identity (id/permalink), purpose, and rough return shape. Missing only error/not-found behavior, which is minor given the tool's low complexity and lack of an output schema.

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

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

Schema coverage is 100%, so the baseline is 3, but 'Pass either id or permalink' adds the either/or selection constraint that the schema itself does not express (both params are optional with no mutual-exclusion rule). That is genuine value beyond the structured field descriptions.

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 ('Get one component') and adds the payload scope ('full html, css and js'), which cleanly separates it from the plural sibling list_components. It does not explicitly name or contrast with a sibling, so it falls just short of the top tier.

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 guidance is 'Pass either id or permalink', which is parameter selection, not when-to-use. There is no statement of when to reach for get_component versus list_components or the other component CRUD siblings, and no prerequisites or exclusions.

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

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

No annotations are provided, so the description carries the burden. It usefully discloses that the response contains full html/css/js (implying a potentially large payload), but says nothing about permissions, error behavior, or draft/published state handling.

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 waste, with the payload description front-loaded ahead of the calling convention. Every clause 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 simple two-parameter read tool with no output schema and no annotations, the description covers what the resource is, what the response contains, and how to identify it. Missing only auth/error context, which is minor at this complexity.

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

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

Schema coverage is 100%, so the baseline would be 3, but the description adds the mutual-exclusivity contract ('pass either id or permalink') that the schema does not encode — both params are optional with no oneOf constraint. That is real value 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 ('Get one page') and adds genuinely useful scope: the return includes full html, css and js. It does not explicitly differentiate from siblings like get_post or get_component, but 'page' is a distinct resource in this toolset.

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?

'Pass either id or permalink' implies the calling convention, but there is no guidance on when to use this versus list_pages or get_post, nor any stated prerequisites. Usage is implied rather than explained.

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. 'Get' implies a read-only, non-destructive fetch, which is the key behavioral trait, but nothing is said about behavior when the id does not exist (error vs empty), permissions, or return shape.

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 wasted words. It is efficient, though its brevity is also part of the reason the usage and behavioral gaps remain.

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 read tool with no output schema, the description is minimal but mostly sufficient to call it correctly. It does not describe the returned post shape, and with no output schema available the agent has no other source for that.

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 the single id parameter is fully documented in the schema. The description's 'by id' merely restates the schema and adds no syntax, format, or edge-case detail beyond it.

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+resource ('Get a single blog post') and the word 'single' implicitly distinguishes it from the sibling list_posts. However, it never names list_posts/create_post/update_post as alternatives, so it falls 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.

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

The description states what the tool does but offers no when-to-use guidance, no mention of the sibling alternatives (list_posts, get_page), and no prerequisites. The usage context is left entirely to inference from the name.

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 content of the returned settings (GDPR popup, theme colours, robots.txt, maintenance mode, reCAPTCHA key). However it says nothing about read-only semantics, required permissions, or whether settings may be absent — gaps that matter for a config-reading 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 that leads with the verb and resource, then qualifies scope. The parenthetical list is long but each item genuinely defines the boundary of the response.

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 correctly compensates by enumerating the returned settings. With no annotations, however, it omits any safety/permission context an agent might want before calling a configuration reader.

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?

Zero parameters, so the baseline is 4; there is nothing for the description to clarify beyond the schema. The enumerated return fields are extra context, not parameter documentation.

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 ("Get site-wide settings") and enumerates the settings returned, which sharply delimits scope. It does not name the sibling update_site, but the read/write distinction is unambiguous from the 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 when-to-use guidance, no prerequisites, and no mention of the obvious alternative update_site for writing these same settings. The agent must infer that this is the read counterpart to update_site from the name alone.

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 behavioral burden. It usefully discloses that results are summaries and exclude html/css/js, but says nothing about auth requirements, ordering, result limits, or pagination.

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 scope constraint front-loaded before the routing hint.

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 no-parameter list tool with no output schema, the description covers what is returned at a useful level (summaries, no markup) and where to go for full content. Missing only pagination/ordering behavior, which is minor here.

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 takes zero parameters, so the baseline is 4. Nothing in the description is needed to explain inputs, and none is wasted on them.

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 (List) and resource (the customer's components) and qualifies the payload as summary-only. An agent can distinguish it from get_component without opening either schema.

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

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

It explicitly names the sibling alternative and the condition that selects it ('Use get_component for content'). It does not cover prerequisites, pagination context, or when listing is unnecessary, but the routing guidance is unambiguous.

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 returned entries include public URLs suitable for page HTML, which is real behavioral context. It does not state pagination, ordering, size limits, or whether the operation is read-only (though 'List' strongly implies it).

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 (library scope, content types, public URL return, intended use) 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 zero-parameter read tool with no output schema, the description covers what the tool returns (media with public URLs) and why it matters. It stops short of describing result shape or pagination, but nothing critical for invoking it 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?

The tool takes zero parameters, so the baseline is 4. The schema is empty and the description correctly indicates no filtering input is required or offered.

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 (List) and resource (customer media library), and adds scope detail by naming the content types (images, PDFs). This clearly separates it from upload_media and delete_media siblings, though it does not explicitly name them.

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 phrase 'to use in page HTML' implies the context in which this list is needed, giving implied usage guidance. However, there is no explicit when-to-use versus when-not, and no mention of alternatives such as fetching a single item.

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 behavioral burden. It usefully discloses that results are summaries without html/css/js content, which saves the agent from expecting page bodies, but says nothing about ordering, pagination, size limits, or permissions for a read/list operation.

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

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

Two short sentences, no filler. The scope constraint (summary only) is front-loaded and the routing pointer follows, so the most decision-relevant information comes 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?

With no output schema and no annotations, the description must explain the return shape, and it does so by stating results are summaries without html/css/js. That is sufficient for a simple parameterless list tool, though a note on pagination or result ordering would make it fully self-contained.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The schema itself is an empty object, and the description correctly adds no parameter guidance because none is needed.

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 (List) and resource (the customer's pages), plus a scope qualifier (summary only, no html/css/js). This clearly separates it from get_page, which the description names, so an agent can distinguish it from siblings without opening a schema.

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

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

Explicitly routes to the right alternative: 'Use get_page for content,' which tells the agent when NOT to use this tool. It stops short of stating full usage conditions (e.g. pagination, ordering, or whether it lists across all sites), so it is clear but not exhaustive.

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

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 pagination behavior and page size (15 per page), which is genuinely useful. It omits ordering, permissions, and return-shape details, so it only partially covers the behavioral surface.

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 tight sentence with zero filler, and the pagination constraint is front-loaded immediately after the purpose.

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

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

For a simple one-parameter list tool with no output schema, the description covers the essentials of pagination but says nothing about what a returned post contains or how results are ordered. 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 0% for the single 'page' parameter, so the description must compensate. Saying 'paginated, 15 per page' gives the agent the page semantics and page size, which meaningfully clarifies the parameter, but defaults and bounds are still undocumented.

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

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

States a specific verb and resource ('List blog posts'), which is clear enough to distinguish it from get_post, create_post, and update_post in the sibling set. However, it does not explicitly name or differentiate itself from any sibling, leaving the agent to infer the boundary.

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 get_post (single post) or list_pages. No prerequisites, filters, or context for selection are given.

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 the return shape (from_permalink -> to_permalink pairs), which is more than most list tools offer, but says nothing about read-only safety, pagination, result limits, or auth requirements.

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 with no waste, front-loading the verb and resource and using the parenthetical to convey the output shape in three words.

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

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

For a parameterless, read-only list tool with no output schema, the description covers what it returns and at what scope. It falls short only on pagination/volume expectations, which an agent might need for a potentially long list.

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 schema has zero parameters, so there is nothing to document and the baseline of 4 applies. The description correctly implies the tool is unscoped beyond the site, consistent with an empty input 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 (List) and resource (path redirects) and clarifies the data shape with the from_permalink -> to_permalink notation. It implicitly separates itself from the create_redirect/delete_redirect siblings by verb, but never names them or explicitly frames this as the read-only counterpart.

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 when-to-use guidance, no prerequisites, and no mention of the sibling tools that mutate the same resource (create_redirect, delete_redirect). 'for the site' hints at scope but gives no conditions or exclusions for an agent to reason about.

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 the replacement semantics ('Replaces the previous one'), which tells the agent this is a mutating, idempotent-per-site operation, plus format/size constraints. However it omits auth/prerequisite requirements and any response behavior.

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

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

Two compact sentences with the core action front-loaded, then constraints, then the replacement caveat. No filler.

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

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

For a 2-param mutation tool with no annotations and no output schema, the description covers formats, size limit, source, and replace behavior, which is solid. Gaps remain around path/url mutual exclusivity and prerequisite permissions.

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

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

Schema coverage is 0%, so the description must compensate. 'From a local path or URL' indicates the purpose of both parameters (path, url) and adds value, but does not state whether they are mutually exclusive, which one wins if both are supplied, or the format expected for path.

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 (set/upload) and resource (site favicon), and implicitly distinguishes itself from the sibling set_logo by naming 'site favicon' specifically. The accepted formats and size cap add concrete detail beyond the name.

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 indication of when to use this versus set_logo, list_media, or upload_media, and no guidance on choosing the path vs url parameter. Usage is only implied by the resource name.

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 one genuinely important trait: the operation replaces the previous logo. However, it omits permissions/auth needs, accepted image formats or size limits, and whether other references to the old logo are updated.

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 action and resource, with no filler. It is terse to the point of under-specification, but nothing is 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?

For a mutation tool with no annotations, no output schema, and 0% parameter documentation, the description leaves too much unspecified: parameter choice, image constraints, and side effects beyond replacement. It is not adequate for correct invocation.

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

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

Schema description coverage is 0% for both 'url' and 'path', and the description says only 'Upload the site logo image', leaving it unclear which parameter to supply, whether both are alternatives, or how they interact. With zero required parameters, the agent gets no help deciding what to send.

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 ('Upload'/'set') and resource ('the site logo image'), plus the scope where it applies: CMS templates and email branding. That distinguishes it from set_favicon and the generic upload_media sibling, though it never names an alternative explicitly.

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 verb makes clear this is the tool for setting the site logo. There is no guidance on when to use this versus upload_media or set_favicon, and no prerequisites or exclusions are given.

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 one genuinely important mutation trait: a day sent replaces that day, [] closes it, and unsent days are untouched. It says nothing about auth requirements, whether omitted scalar fields (timezone, buffers, notices) are also left unchanged, or whether the operation is reversible, leaving material behavioral gaps 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?

Two sentences, no padding, with the core action front-loaded and the trickiest parameter's semantics immediately after. It is dense but readable; a semicolon-heavy sentence is the only minor structural cost.

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 6-parameter mutation tool with no annotations and no output schema, the description covers availability semantics well but leaves the update semantics of the other five settings unstated, and gives no permission or side-effect context. An agent can call it, but it cannot confidently predict the effect of omitting scalar fields.

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 17% (just timezone), so five of six parameters rely on their names alone. The description compensates well for availability, giving the day-key domain (MONDAY..SUNDAY), the ["HH:MM","HH:MM"] range shape, and replace/close/no-op semantics that the schema does not express, but it adds nothing for max_advance_days, buffer_before/after_minutes, or minimum_notice_hours.

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

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

The description states a specific verb and resource ("Update booking settings and weekly hours") that clearly matches update_booking_setup and pairs off against the read-only sibling get_booking_setup. It does not name the sibling explicitly, but the purpose is unambiguous and distinct from the media/page/post/component tools around it.

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 the get_booking_setup alternative for reading current values, and no prerequisites such as required permissions or scopes. The partial-update rule ("days not sent are unchanged") hints at usage but is really parameter semantics rather than routing guidance.

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

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

With no annotations, the description carries the full burden and does real work: it discloses partial-update semantics per field, that html/css/js are replaced wholesale (not merged), and that a revision is recorded. It omits permission/auth requirements and any effect on the public site, but the mutation behavior is well disclosed.

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, front-loaded with the action, then the two most consequential semantics. Every sentence earns its place with no filler.

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

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

For a 7-param mutation tool with no output schema and no annotations, the description covers the key update semantics. It does not address permissions, permalink/site-wide component implications, or rollback of the recorded revision, leaving minor 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 coverage is already 86%, so baseline is 3. The description adds genuine meaning beyond the schema by distinguishing scalar fields (partial merge) from html/css/js (wholesale replacement), which is a semantic distinction the schema itself does not state.

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 (update) and resource (component), clearly distinguishing it from get_component/create_component/delete_component by name. It does not explicitly differentiate from the parallel update_page sibling, but the resource 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?

Usage context is implied rather than stated: patch semantics ('only the fields you pass are changed') tell the agent how to call it, but there is no guidance on when to choose update_component over update_page or create_component, and no prerequisites.

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 at all, the description carries the full behavioral burden. It usefully discloses PATCH semantics (only provided fields are mutated, so unlisted fields are preserved) and the side effect of enabled=false, but says nothing about authorization requirements, whether changes are reversible, or what happens to the other optional fields when omitted.

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 clauses, front-loaded with the core action and immediately followed by the two most decision-relevant details (selective mutation, how to hide). No filler; only knock is that it is quite sparse for a six-parameter mutation.

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 zero annotations, no output schema, and six parameters at 17% coverage, this is under-specified. The agent learns the update is partial and that enabled=false hides the type, but not the meaning of length/cost/name or any permission 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?

Schema coverage is only 17% (just id's "Numeric id"), so the description must compensate for five undocumented parameters. It adds marginal value by explaining partial-update behavior across all optional fields and the enabled flag's effect, but leaves cost, name, length (an unexplained string, oddly typed for a duration), and description completely undescribed.

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 meeting type"), which clearly distinguishes it from the create_/delete_/list_meeting_type siblings without needing to name them. It stops short of explicitly routing to those alternatives, but the operation 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?

Usage is implied rather than stated: "only provided fields change" tells the agent this is a partial update (don't re-send everything) and "Set enabled=false to hide it" gives one concrete usage path. There is no explicit when-to-use-vs-alternatives guidance or prerequisite/permission note.

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 does well: it discloses partial-update semantics, that html/css/js are replaced wholesale rather than merged, and that a revision is recorded as a side effect (implying history/audit and potential recovery). It omits permission requirements and what happens to fields left unset beyond 'unchanged'.

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, tight and front-loaded with the core action, then the two behavioral facts that matter most (replacement vs partial, revision recorded). No filler.

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

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

For an 11-parameter mutation tool with no annotations and no output schema, this covers update semantics and side effects well. It could be slightly more complete by noting that id must reference an existing page or that the tool requires owner-level access, but nothing essential to invoking it 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 coverage is 82%, so the baseline is 3, but the description adds genuinely new meaning the schema lacks: which fields are wholesale-replaced (html, css, js) versus left untouched. That distinction directly affects how an agent should pass values and is not stated anywhere in the schema descriptions.

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 ('Update a page'), which is clearly distinct from the sibling create_page, delete_page and get_page operations. It does not explicitly name those siblings or contrast behavior with them, 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?

Usage is implied by the update semantics and the 'only the fields you pass are changed' note tells the agent this is a partial-update call, but there is no explicit when-to-use guidance (e.g. use get_page first to obtain current values, or update_component for component-level changes).

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 non-obvious behaviors: partial-update semantics ('only provided fields change') and array-replacement semantics ('tags replace the full set'). It still omits permission requirements, error behavior for an invalid id, and whether a field can be cleared, so coverage is partial rather than complete.

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 with zero filler, and the partial-update rule is front-loaded immediately after the purpose statement. Nothing is repeated from the schema.

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?

A 9-parameter mutation tool with no annotations, no output schema, and 33% schema coverage needs a richer description. Key gaps remain: how to clear a field when omitted fields are preserved, whether updates are idempotent, and any permission or validation-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?

Schema coverage is only 33% (id, body, date documented; tags, draft, title, subtitle, permalink, read_time bare). The description rescues the important tags parameter by clarifying replacement-not-merge, but the remaining six undocumented parameters are left with neither schema nor prose semantics.

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

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

States a clear verb+resource: 'Update a blog post'. The resource noun distinguishes it loosely from update_page, but the description never explicitly contrasts the two siblings, so an agent must infer that posts and pages are different entities.

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 prerequisite (e.g., fetch with get_post first), and no explicit routing away from update_page or toward create_post. The agent is left to infer usage entirely from the name.

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 add real value by disclosing partial-update semantics ('Only provided fields change') and by warning that head_js injects raw HTML into <head>, which is a security-relevant detail. It omits permissions/auth requirements, reversibility, and any side effects of maintenance_mode or recaptcha changes.

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 tight sentences, front-loaded with purpose, followed by the update semantics and the two most nuanced parameters. Every sentence contributes, though the final sentence is somewhat param-specific and could be marginally tighter.

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 13-parameter mutation tool with a nested object, no annotations, and no output schema, the description covers only the partial-update behavior and two parameters. Permission requirements and the effects of enabling maintenance_mode or gdpr_popup are left unexplained, so the coverage is adequate but 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?

Schema coverage is 62%, so the schema already documents several parameters. The description meaningfully supplements global_css (schema has no description) by stating it applies to every page, and reinforces head_js usage, but says nothing about the other eleven parameters, including the nested gdpr_config object.

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 opens with a specific verb+resource, 'Update site-wide settings', which is unambiguous. However, it does not distinguish itself from sibling tools that also mutate site-level configuration, notably set_favicon and set_logo, leaving the boundary between them to inference.

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 guidance on when to use this tool versus set_favicon, set_logo, or update_booking_setup. The phrase 'Only provided fields change' hints at partial-update behavior but is not framed as usage direction, and no prerequisites or exclusions are given.

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 does disclose several traits beyond the schema: the size ceiling, the accepted MIME types, and the return value (a public URL). It is silent on auth/permission requirements, what happens if the 10MB limit is exceeded, or whether an existing item with the same name is overwritten, which are the higher-value disclosures for an upload mutator.

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 with zero filler. Format and size constraints are front-loaded, and the return-value note lands last where it is most useful.

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 three-parameter upload tool with no annotations and no output schema, the description covers capabilities, constraints, and the return value (so the absent output schema is less of a gap). The main omission is any statement about permissions or failure/overwrite 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?

Schema description coverage is 100%, so the schema already explains url, path, and name. The description restates the path-vs-URL duality but adds no format, precedence, or conflict rules beyond what the schema provides. Baseline 3 is appropriate 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?

The description gives a precise verb+resource ('upload an image or PDF'), enumerates accepted formats (jpg, png, gif, svg, webp, pdf), states a hard limit (max 10MB), and names both input modes. It is unmistakably distinct from its list_media and delete_media siblings without needing to name them.

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: the closing clause 'reference in HTML' hints at the intended workflow, and 'from a local file path or a remote URL' tells the agent the two input modes. However, there is no explicit when-to-use/when-not-to-use guidance or reference to an alternative tool.

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