uCoz

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

Annotations already flag destructiveHint=true, but the description adds the important permanence trait ('Cannot be undone') and the breadth of destruction targets, which is real context beyond a generic destructive flag. It stops short of describing the confirm/user-approval gate or any permission requirements, which live only in the schema.

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 resource scope and closed with the irreversible-outcome warning. No filler, nothing repeated from the name/title.

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 21-parameter, multi-action destructive tool, the description establishes purpose and irreversibility but omits the operational workflow: that an action is required to select the deletion type, that confirm must only be passed after user approval, and that ids should come from listing tools. With a fully documented schema these gaps are partly absorbed, but the description alone would leave an agent underspecified.

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 each action's oneOf entry already lists required and optional parameters, so the schema does the parameter work. The description only implies a mapping between listed resource types and the action enum, adding no syntax or format detail 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?

The description names a specific verb (deletes) and enumerates the exact resource families covered: files, databases, database users, FTP accounts, cron jobs, Node.js/Python apps and keys, matching the action enum. It is clear what the tool does, though it doesn't explicitly carve out territory versus overlapping siblings such as files_delete or ftp_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?

Usage is only implied through the scope phrase 'of the server environment'. There is no statement about when to pick apps_delete over apps_write or the narrower files_delete/ftp_delete/cron-style siblings, and no prerequisites (e.g. gather ids from cron_list/ftp_list first) are mentioned.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety behavior is covered. The description adds scope ("active site") and lists covered resource categories, but does not disclose prerequisites, pagination behavior, or output characteristics beyond what the schema's action descriptions provide.

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

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

The description is a single front-loaded sentence that efficiently states the tool's scope. The long enumeration is justified by the tool's breadth, though it could have used that space to clarify routing among overlapping siblings.

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?

The tool is highly complex with 32 actions and 17 parameters, and the schema is very rich. The description provides an adequate broad overview but does not explain how to choose among actions, how to interpret results, or how this tool relates to overlapping read-only siblings. It relies almost entirely on the schema for completeness.

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

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

Schema description coverage is 100%, and the action enum's oneOf entries document each operation's parameters and return behavior in detail. The top-level description adds only a broad resource list and no parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.

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 ("Reads") and resource ("server environment of the active site") and enumerates the data categories covered. It is clear what the tool does, but it does not explicitly distinguish itself from read-oriented siblings such as files_read or settings_read.

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 gives no explicit guidance on when to use this tool versus alternatives. This is especially problematic because sibling tools like files_read and settings_read overlap with actions exposed here (files_read, php_get, etc.), and the definition does not explain whether to use apps_read or the dedicated sibling.

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?

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the safety profile is covered. The description adds real value on two points: login key values are never returned and phpMyAdmin links are one-time. It omits other consequential behavior that isn't in annotations, such as published files landing in public_html and requiring manual cleanup (only visible in the oneOf branch text).

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?

Single run-on sentence that front-loads the core purpose, then lists roughly ten capability clusters in a breath. Each cluster is real, but the catalogue is hard to scan and largely restates what the action enum already lists action-by-action.

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 that the action enum carries per-action requirements and all 51 parameters are fully documented in the schema, the description needs only to frame the tool's domain, which it does. The absence of an output schema is not a problem since the branches describe return values (password_once, download URLs, stored_path).

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 oneOf branches enumerate required/optional params per action, so the schema does nearly all the work. The top-level description adds no parameter syntax, defaults, or dispatch hints beyond what the enum already encodes, making the baseline 3 appropriate.

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?

Opens with a specific verb and resource ('Creates and changes the server environment of the active site'), which distinguishes it from apps_read and apps_delete. The enumerated capability list confirms its scope as a broad write surface, though the enumeration is more of a catalogue than a purpose statement.

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 pick this tool over alternatives, and the sibling list contains direct competitors whose names mirror its actions (files_write vs. action files_write, ftp_write vs. ftp_create/ftp_passwd). It also never explains that most actions need confirm=true and user approval first, which the schema buries in the confirm property.

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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description's addition of "Cannot be undone" genuinely confirms permanence — information a hint alone doesn't convey — but it stops there: nothing about required permissions, what happens to dependent records (e.g. comments on a deleted entry), or whether the confirm flag can be bypassed programmatically.

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 filler, with scope stated first and the irreversibility warning front-loaded at the end where it lands hardest. Nothing repeats the title or 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?

For a six-parameter destructive tool with full schema coverage and no output schema, the description covers what is deleted, from where, and that it's permanent. The remaining gaps — the user-approval gate for confirm, the forum exclusion, and the module/polls alias — are all handled in the schema, so nothing critical is missing, though a one-line cross-reference to content_write would have made it 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% and the action enum's oneOf entries already spell out per-action required parameters (id vs channel_id vs filter_num). The description adds no format or behavioral detail beyond the resource vocabulary that maps loosely to the action values, so it sits at the baseline rather than adding value.

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

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

States a specific verb (deletes) plus the exact resource set (entries, categories, comments, filters, video channels) and scopes it to a content module of the active site. An agent immediately knows what this destroys, though the description itself does not differentiate it from the sibling content_write or point to forum_delete for forum content — that distinction only appears in the schema's module field.

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 choose this tool over content_write or the module-specific *_delete siblings, and no mention of prerequisites such as selecting a site first. The only directional statement is a consequence ("Cannot be undone"), which warns but does not route.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only the 'active site' context and the module/resource scope; it says nothing about pagination, truncation, or return behavior beyond what the schema's detail/offset params already document.

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 the verb first and no filler. The parenthetical module-code list partly duplicates the schema enum, a minor redundancy, but the sentence remains tight 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 a complex 11-action, 15-parameter tool with no output schema, the one-line description is thin on return-value and paging behavior, though the action enum and detail parameter in the schema compensate substantially. Adequate but not 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?

Schema description coverage is 100% and the action enum carries per-action required/optional parameter detail, so the schema does the heavy lifting. The description itself adds no parameter meaning, which is the baseline 3 case when coverage is high.

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 ('Reads') and enumerates concrete resources (entries, categories, comments, filters, albums, video channels) plus the supported module codes. It clearly conveys the content-reading scope, but it does not explicitly differentiate itself from the content_write/content_delete siblings, relying on the name instead.

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, when-not, or alternative guidance; it is a single scope sentence. Prerequisites (an active site) are only implied by 'on the active site', and the routing hints (e.g. forum_* tools, comments_all needing no module) live in the schema, not the description.

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?

Annotations already declare destructiveHint=true, openWorldHint=true, and readOnlyHint=false, so the safety profile is largely covered. The description adds that entries are published to the site, but it omits permission requirements, irreversibility, moderation behavior, and upload constraints that appear only in the schema.

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

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

The description is two sentences with no wasted wording and is front-loaded with the main capabilities. The second sentence adds the important publish side effect without repetition.

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?

This is a complex 103-parameter, multi-action destructive tool, and the description is minimal at the top level. However, the schema's per-action oneOf descriptions document required and optional fields extensively, and annotations cover the safety profile; no output schema means return values need not be explained 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?

Schema description coverage is 100%, so the baseline is 3. The description broadly maps capabilities to resource types, but with 103 parameters it adds no parameter-level detail beyond the very rich schema and action oneOf 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?

The description names specific verbs and resources: creates and updates entries, categories, comments, filters, and video channels, plus tags and rates entries. This clearly distinguishes a write tool from content_read and content_delete, although it does not explicitly name those siblings.

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 write verbs and the phrase 'active site,' so an agent can infer this is for mutations. However, the description gives no explicit when-to-use guidance, exclusions, or alternatives such as content_read, content_delete, or forum_write.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the non-obvious side effect that the new site becomes the active site, which is meaningful state-change context beyond the annotations. It stops short of disclosing failure behavior, uniqueness constraints, or quota 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 front-loaded sentence with no filler. The side effect is placed at the end where it naturally follows the core action, and nothing is 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 simple 3-parameter creation tool with full schema coverage and annotations, the description covers the action, target, and side effect. It omits the 'lng' parameter and any failure/duplicate-address behavior, but no output schema exists so return values need not be explained.

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%, with the 'dom' enum codes fully mapped to hosts and 'addr'/'lng' constraints documented in the schema. The description only restates 'at the given address and zone' without adding format or validation detail, 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?

Uses a specific verb+resource ('Creates a new uCoz site') and states scope (signed-in account) and side effect ('makes it the active site'). An agent can distinguish it from list_sites and select_site purely from the description.

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 verb — this is the only site-creation tool among siblings, so no alternative needs naming. However, it gives no prerequisites (auth requirements, whether the address must be free, quota limits) and no explicit when-to-use framing.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and openWorldHint=false, so the safety profile is fully covered. The trailing "Read-only" merely repeats readOnlyHint and earns no credit. The description adds little behavioral context beyond the schema-documented URL constraint (only https://api.ucoz.net/{module}-openapi.yaml accepted), leaving it at a baseline 3.

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, cleanly ordered purpose-then-capabilities-then-safety. It loses a point only because the closing "Read-only" is redundant against the annotations and could be dropped without loss.

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 5-parameter, enum-driven tool with 100% schema coverage and no output schema, the three modes are adequately described and it notes that fetch_spec returns a full specification. It could still say more about the shape/limits of returned specs (e.g. that results are YAML text), but nothing an agent needs to select or invoke 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 100%, so the schema already documents all five parameters including the enum, ranges, and URL format restriction. The description contributes no additional parameter detail (no default hints, no interaction notes between action and module/query), 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 and resource ("Looks up the uCoz uAPI OpenAPI specifications") and enumerates its three modes — list, search, fetch — each mapping directly to an action enum value. No sibling tool provides documentation lookup, so it is trivially distinguished from the *_read/write/delete family.

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 describes what the tool does but never states when to reach for it (e.g. before invoking a uAPI method) or any exclusions. Usage is only implied by the action enum in the schema, not spelled out in prose. No alternatives exist among siblings, so the omission is less severe, but explicit guidance is absent.

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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known from structured data. 'Cannot be undone' largely restates destructiveHint, though the framing that folders as well as files are removed adds a small amount of scope information. It says nothing about batch semantics (path + paths), partial failures, or the confirm gate, all of which remain in the schema.

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 waste; the action and its irreversibility are both front-loaded. Nothing is repeated or padded.

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 tool with two required parameters and batch support, the description is thin: it never mentions that multiple targets can be supplied, that missing targets fail the whole request, or that a confirm flag must be set. The rich schema and annotations compensate, making it adequate but with clear gaps for a high-risk 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%, including detailed path rules, the paths/path relationship for delete, and the confirm requirement, so the baseline of 3 applies. The description adds no parameter-level information beyond what the schema already documents.

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 ('Deletes files and folders from the site file manager'), so an agent can tell it apart from files_read/files_write. It doesn't explicitly name the nearest destructive siblings (content_delete, ftp_delete) to route between 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?

There is no guidance on when to use this tool versus alternatives such as content_delete or ftp_delete, and no mention of prerequisites or when deletion should be avoided. The only usage-adjacent statement is the irreversibility warning, which is a consequence rather than a selection rule.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds almost nothing beyond them; the one useful nugget, that only text files can be read, is stated more completely in the schema's content_get entry. No mention of auth requirements, size 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?

A single front-loaded sentence that leads with the primary list capability and then covers the secondary actions. Nothing is padded, though for a 4-action, 10-parameter tool the compression is close to under-specification rather than tight writing.

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 return values are opaque at the description level, and with four distinct actions and ten parameters the one-sentence summary is thin. It is rescued by unusually rich enum and parameter descriptions in the schema, which supply the action-to-parameter mapping, but the overview itself does little for an agent deciding between content_get and content_read.

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 action enum's oneOf entries exhaustively document which parameters each action takes, so the description need not carry parameter meaning. It adds none, which is the correct baseline of 3 when the schema does all the work.

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 names the resource (site file manager) and four concrete operations: list, info, quota, and read text content. It is clearly a read-side tool, so it is distinguishable from files_write and files_delete. It stops short of naming any sibling explicitly, which keeps it at 4 rather than 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?

It enumerates what the tool can do but never says when to choose it over alternatives — notably content_read, which appears to overlap with content_get, or when a caller should use files_write/files_delete for the mutation side. The only routing signal is the action enum, which is schema data, not description 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?

The annotations already declare destructiveHint=true and openWorldHint=true, but the description does not explain what may be overwritten or destroyed, whether operations are atomic, how partial per-item failures behave, or what permissions are required. It mostly restates the operation list already present in the schema.

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

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

The description is a single front-loaded sentence with no filler, which is appropriately concise. However, for a multi-action destructive tool, the flat operation list could be structured more helpfully around action selection.

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?

The schema is unusually rich, with per-action oneOf descriptions and full parameter documentation, and the annotations cover the safety profile. The description itself remains minimal and omits sibling routing and overwrite/destruction specifics, so it is adequate but not fully complete for a complex 18-parameter write tool.

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

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

Schema description coverage is 100%, so the schema already documents all 18 parameters and the action enum in detail. The description only broadly mentions text, base64, and URL uploads and does not add parameter-level meaning beyond that baseline.

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 names specific write operations: uploading files, writing text, creating folders, renaming and moving items in the site file manager. It clearly identifies a file-mutation tool, but it does not explicitly distinguish itself from siblings such as files_read, files_delete, or content_write.

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 operations are available but gives no guidance on when to use this tool versus files_read, files_delete, content_write, or other write tools. It also omits prerequisites and conditions for choosing among its own actions, leaving selection to the schema.

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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered; the description adds the irreversibility detail ('Cannot be undone'), which is real value. However, it omits important behavioral facts such as whether deleting a forum cascades to its topics/posts, and that confirm must be true only after user approval — that lives only in the schema.

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 scope of deletion and immediately followed by the irreversibility warning. Nothing is wasted or buried.

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 destructive tool with no output schema, the description is adequate but thin: it says what gets deleted and that it is permanent, while the cascade behavior and the human-approval requirement are left to the schema. An agent reading only the description would have an incomplete model of consequences.

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 oneOf entries already explain per-action id requirements and the confirm flag, so the schema does the heavy lifting. The description's list of entity types loosely mirrors the five actions but adds no id-format or precedence detail beyond what the schema states.

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 ('Deletes') and enumerates the exact resource types covered (forums, sections, topics, posts, polls), which maps cleanly onto the action enum. It is clearly distinguishable from sibling forum_read and forum_write by its destructive scope, though it never names those siblings 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 enumeration of entity types plus 'Cannot be undone' signals a destructive operation to be used deliberately. There is no explicit guidance about when to choose this over forum_write, nor any mention of the approval/confirm workflow that the schema requires.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description adds only that reads are scoped to the active site, which is genuinely useful context, but says nothing about pagination caps, brief-vs-full defaults 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?

A single front-loaded sentence with no filler, and the scope ('active site') is placed at the end where it reads naturally. It is arguably too thin for a ten-action tool, but there is no wasted text to trim.

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 ten-action tool with eleven parameters and no output schema, one sentence leaves the dispatcher model, paging behavior and site-scoping mechanics entirely to the schema. The schema is rich enough to carry most of that load, but the description does not prepare an agent for the action-per-call pattern.

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%: every action variant and every parameter (id, page, per_page, offset, detail, and each entity id) is documented in the oneOf entries and property descriptions. The description contributes nothing 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?

The verb 'Reads' plus the enumerated resources (forums, sections, topics, posts, polls) states exactly what data the tool surfaces and implicitly separates it from forum_write and forum_delete. The one gap is that it never mentions the action-dispatcher design, so the multi-operation nature only becomes visible in 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?

There is no statement of when to choose this over forum_write/forum_delete, no mention that a site must first be selected via select_site, and no guidance on choosing among the ten actions. Only the phrase 'active site' hints at a prerequisite, and it is left unexplained.

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?

Annotations already declare readOnlyHint=false and destructiveHint=true, so the description's main added duty is to explain consequences, permissions, or gating — none of which it does. The operation list merely restates the action enum, adding no behavioural context such as irreversibility of deletes/moves or that confirm gates destructive actions.

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 enumerating the operation families, with no filler. It is somewhat redundant with the action enum but remains an efficient one-line summary for a 27-parameter tool.

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?

The enormous action enum and 100% parameter documentation in the schema carry most of the burden, so the description need not repeat parameters. However, for a destructive, 27-parameter write tool with no output schema, it should at minimum flag the confirm requirement and the read/delete siblings, which it does not.

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 each oneOf action entry documents its own required and optional fields, so the schema already carries full parameter meaning. The description adds nothing parameter-specific (e.g. the overloaded id/name fields or required action), 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 uses concrete verbs and resources ('creates and updates forums, sections, topics, posts and polls; closes, pins, moves, joins and splits') that accurately mirror the action enum, so an agent knows exactly what class of operation this tool performs. It stops short of distinguishing itself from the sibling forum_read and forum_delete tools, which is the missing piece for 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 statement of when to use this tool versus forum_read (read) or forum_delete (delete), and no prerequisites or ordering advice. It also never mentions the approval workflow encoded in the confirm parameter, which is essential guidance for the join/split/move actions.

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?

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds real consequence detail the annotations cannot convey: FTP login breaks until a new password is set and the old password is unrecoverable. The confirm gate and the 'fails when no password is set' condition live in the schema rather than the description, so it is not fully self-contained on 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?

Three short sentences with the consequence front-loaded, which is the right order. The final sentence about apps_delete is garbled ('with apps_delete ftp_delete instead'), costing clarity in what should be a crisp disambiguation.

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-parameter destructive tool with full schema coverage and no output schema, the description covers irreversibility, the resulting broken-login state and the sibling to use for a different deletion. The only gap is the imprecise cross-reference sentence and no mention of how to restore service beyond naming ftp_write.

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 enum documents the single action plus its required confirm parameter in detail. The description adds no parameter-level syntax or format information beyond what the schema already provides, 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?

States a specific verb and resource (remove the FTP password of the active site) and immediately delimits scope against two siblings: ftp_write to set a new password and apps_delete for deleting an FTP account. An agent can distinguish this from every other ftp_* and *_delete tool 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?

Gives clear when-to-use context (only for the password of the active site) and names the alternative path for a related-but-different operation (deleting an FTP account via apps_delete). No explicit exclusions such as prerequisites for the 'active site' selection, and the final cross-reference sentence is grammatically mangled, which slightly blunts the 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?

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds useful behavioral context by stating that the password is never returned and that the tool does not change anything, though the latter largely reinforces the annotations.

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

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

The description is three tight sentences with the primary return behavior front-loaded, followed by security behavior and sibling routing. Every sentence contributes useful selection or invocation context.

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 tool with rich annotations and a fully documented one-parameter schema, the description supplies the remaining needed context: what is returned, that the password is excluded, and which sibling tools to use for related tasks. No output schema is present, but the return fields are named in the description.

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 is only one parameter, and the schema documents it fully with a 100% schema description coverage and an enum value describing the operation. The description does not add parameter-level semantics beyond the overall tool purpose, so 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 uses a specific verb and resource: it returns the FTP connection details of the active site, and it enumerates the returned fields (host, port, user name, password-set status). It also clearly distinguishes the tool from files_read and apps_read ftp_list, so an agent can identify its purpose 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 explicitly routes adjacent needs: site files are read with files_read, and server-environment FTP accounts are listed with apps_read ftp_list. It also states that the tool does not change anything, which excludes mutation use cases, leaving little ambiguity about when to call this tool.

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

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

Beyond destructiveHint=true, the description discloses the concrete consequence (the old password stops working) and the response contract (connection details returned without the password), plus the user-approval requirement implied by confirm. That is exactly the extra context annotations cannot express.

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 its conditional scope, then the side effect, then the response, then the alternative. 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 destructive 3-parameter write with full schema coverage, no output schema, and annotations covering safety, the description supplies the remaining essentials: what gets invalidated, what the reply contains, and where to go for other FTP-account work.

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% — each action, confirm, and the password format are already documented in the schema. The description adds the outcome of the change but no additional parameter syntax or constraints, 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?

Specific verb+resource (sets the FTP password of the active site) with the two states it operates in spelled out (none set vs. replace existing). It also names a sibling (apps_write) for the adjacent FTP-account operations, so an agent can orient it against neighbors.

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?

Clear context for both branches and a routing pointer: FTP accounts of the server environment are created/changed with apps_write, not here. It does not explicitly say when NOT to call it (e.g., prerequisite of selecting an active site), which keeps it just short of a 5; the per-action when-to-use is fully covered by the schema oneOf entries.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the useful scoping detail that results are limited to the signed-in account's sites, but says nothing about pagination or result ordering.

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 no wasted words. The key qualifier ("owned by the signed-in account") is included without preamble.

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 zero-parameter read tool whose safety traits are already declared by annotations, the description is essentially sufficient. The only mild gap is that with no output schema, the description could hint at what a listed site entry contains, but this is minor.

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 schema carries no per-parameter burden and the baseline for a no-param tool is 4. There is nothing further the description could document.

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 ("Lists") and resource ("uCoz sites") with a clear scope ("owned by the signed-in account"). It is clear on its own, though it does not explicitly distinguish itself from the sibling select_site or create_site.

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: an agent would infer this is for discovering which sites exist before selecting or operating on one. There is no explicit statement of when to use it versus select_site, nor any 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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description contributes the useful scoping detail that it operates on the 'active site' and mentions the quarantine-status dimension, but says nothing about pagination limits or result shape beyond that.

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 compact sentence, front-loaded with the primary purpose and scoped to the active site. The second clause slightly overlaps with the first ('installed and available modules' vs 'module status'), but there is no padding.

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 does take on some burden of describing returns, and it does so at a high level (module status, quarantine status) while the schema handles all parameters. Combined with the read-only annotations, an agent has enough to call this correctly, though return fields and pagination behavior are only inferable from the 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 description coverage is 100%: every action variant, the offset semantics, and the module_code format are fully documented in the schema. The description adds no parameter detail 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?

Names a specific verb and resource (lists modules of the active site) and even enumerates the kinds of information returned (module status, indexing quarantine status), so the agent knows exactly what this tool surfaces. It does not explicitly differentiate itself from modules_write/modules_uninstall, but the read/list framing makes the boundary reasonably clear.

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 guidance, no prerequisites, and never names an alternative such as modules_write or modules_uninstall. The action enum lives entirely in the schema, so the description itself gives the agent nothing to route on.

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?

Annotations already set destructiveHint=true and readOnlyHint=false, so the safety profile is declared. The description's "Module data may be lost" sharpens that into a concrete consequence (data, not just config) and adds the "active site" scoping, but says nothing about required permissions, reversibility, or dependency 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 sentences, zero filler, with the action and its risk front-loaded. 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 3-parameter, confirm-gated destructive tool with full schema coverage and explicit destructive annotations, the description is nearly sufficient. It only misses prerequisites such as dependencies or whether data loss is immediate vs deferred.

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 schema itself documents module_code lookup sources and the confirm approval gate. The description adds no parameter-level meaning beyond that, 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?

Specific verb+resource with scope: "Uninstalls a module from the active site." An agent can distinguish it from modules_read/modules_write, though the description never explicitly contrasts uninstall with a disable/deactivate path via modules_write.

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 statement of when to use this versus the sibling modules_write or modules_read tools, and no prerequisites or warnings about dependencies. Usage is only implied by the verb.

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?

Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=false, so the safety profile is covered. The description adds the scoping detail that quarantine_unlock affects the whole site's indexing and that the other actions target a module, but it is largely a restatement of the enum descriptions and says nothing about irreversibility or side effects of disabling uAPI or installing.

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 enumerates all four operations with no filler. It is appropriately sized for a multi-action tool, though the list-form phrasing is slightly dense for an opening line.

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 3-parameter mutation tool with no output schema, the description covers the 'what' but omits usage guidance and confirmation-flow context, relying entirely on the schema and annotations. It is minimally complete but leaves the agent to infer routing and approval semantics.

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%, with per-action oneOf descriptions spelling out required parameters (module_code, confirm) and the enum values documented inline. The description adds no syntax or format detail beyond the schema, so the baseline of 3 is appropriate.

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

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

The description names a concrete verb set (installs, enables/disables uAPI, lifts quarantine) and the resource (module), and it maps cleanly onto the four enum actions. It is clearly a write/mutation tool distinct from modules_read and modules_uninstall, but it never explicitly names those siblings or contrasts itself with 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?

There is no statement of when to use this tool versus modules_read, modules_uninstall, or the *_write siblings, and no mention of prerequisites or the user-approval flow that the confirm parameter implies. The agent must infer all routing and sequencing from the schema 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?

Annotations declare readOnlyHint=false with destructiveHint=false, and the description adds meaningful context beyond them: selecting a site can create an API key if none exists (a real write side effect), and it explicitly reassures that site content is not changed. That resolves the tension between 'not destructive' and 'not read-only'. It does not cover failure cases (invalid site_id) or 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?

Three compact sentences, each earning its place: scope of effect, API-key side effect, and the content-unchanged reassurance, with the primary purpose front-loaded. 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 one-parameter session-state tool with no output schema and non-destructive annotations, the description covers purpose, scope, persistence, and side effects adequately. Minor gaps remain around behavior for an unknown/invalid site_id and whether the selection survives beyond the session boundary.

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 already documents 'Numeric site id from list_sites', so the schema carries the parameter meaning. The description implies which site is targeted but adds no format, range, or validation detail beyond the schema — the baseline 3 for high coverage 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 ('Sets the active site') and immediately scopes it ('for the following calls in this session'), which distinguishes it cleanly from siblings like list_sites and create_site. An agent can tell this is a session-state setter 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?

The description gives clear context for when this tool matters: it configures the site that subsequent site tools will read and change, and the schema points to list_sites as the id source. It does not explicitly name alternatives or state when-not-to-call, so it falls short of a 5.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true and a closed world, so the safety profile is fully covered and 'Does not change anything' is largely redundant. The description adds a little context by scoping reads to the active site, but says nothing about permissions or how access-key redaction is returned beyond what the schema already notes.

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 compact sentence with the purpose and the two sub-behaviors front-loaded, followed immediately by the read-only reassurance. Efficient, though the semicolon clause packs two actions into one long sentence that could be split for faster scanning.

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 carries the return-value burden and does so adequately: it states that the list includes which modules have settings and whether each is active, and that a module's settings come back nested. Minor gaps remain on permissions and truncation behavior, but the schema covers truncation via offset/next.

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 oneOf action entries, the module enum and the offset/next semantics are already fully documented in the schema. The description contributes no additional parameter meaning such as mutual exclusivity rules or defaults, 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 and resource ('Reads module settings of the active site') and enumerates the two concrete behaviors: listing modules with active status, and returning a module's current settings. The scope is narrowed to the active site, so an agent can distinguish it from the sibling settings_write and from app/forum-specific readers 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?

Usage is only implied: the closing 'Does not change anything' signals read-only intent, which points an agent away from settings_write, but there is no explicit when-to-use statement, no conditions, and no named alternatives (e.g. modules_read vs settings_read). The agent must infer the routing.

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?

Annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is partly covered. The description adds genuinely new behavior: only passed keys are written, the response distinguishes changed from unchanged keys, and a dry run previews without saving. It stops short of stating that some changes require confirm or are irreversible, which lives in the action's schema text rather than the description.

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

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

Two sentences, front-loaded with the mutation semantics and followed by the dry-run caveat; no filler, no restatement of the title. Every clause carries information an agent needs.

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 multi-module mutation, the description covers purpose, partial-update scope, result reporting and dry-run preview, while the schema carries the heavy confirm/irreversibility details and annotations flag destructiveness. The one meaningful omission is that the description never signals "some keys require confirm and may destroy data" — an agent skimming only the prose would miss that before opening the action enum text.

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 every parameter carries a rich description, including the enum-constrained action with full confirm semantics and value-shape rules. The top-level description adds no parameter meaning beyond that (module, values, confirm and dry_run are untouched), 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 and resource ("Changes the settings of a module of the active site") plus the key semantic detail that it is a partial update touching only passed keys. It does not explicitly name settings_read or modules_write as the counterpart, so sibling differentiation is left to the tool-name pairing 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: the dry_run sentence hints at a preview-then-commit workflow, and "reports which of them changed" implies verification use. There is no explicit when-to-use versus settings_read, no prerequisite guidance (e.g. needing module knowledge from modules_read or docs_tool), and no when-not 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds the important behavioral detail that deletion 'Cannot be undone' and specifies the full scope of what may be destroyed. It does not cover permissions or confirm requirements, but those are handled by the schema and annotations.

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

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

Two sentences, front-loaded with the core action and resource scope, followed by the irreversibility warning. Every sentence earns its place with 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 multi-action destructive tool with rich schema and annotations, the description is sufficiently complete: it names all affected resource types and warns that deletion is permanent. The action enum details and confirm requirements are fully covered by the schema, though the description could have briefly mentioned that an action parameter selects the specific 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%, so the detailed oneOf action parameter and other fields already document parameter semantics thoroughly. The description itself adds no parameter-specific detail beyond listing affected resources, making the baseline 3 appropriate.

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, 'Deletes,' and enumerates the exact resources affected: products, images, stock records, basket items, comments, and wishlist. This clearly distinguishes it from shop_read and shop_write siblings.

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 destructive operation and the warning 'Cannot be undone,' but there is no explicit guidance on when to choose this over shop_write or other deletion tools, nor any stated 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description's only added context is that reads target the 'active site' (implying a dependency on select_site) and its enumeration of domains; it says nothing about permissions, pagination behavior, or cost of broad reads.

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?

One front-loaded sentence with a clear verb and scope and no wasted clauses. The trailing domain list is a slight dump but each item maps to a real action, so it 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 14-action, 36-parameter dispatcher this is thin: no explanation of how to choose an action, no mention that detail=full is needed for complete records, and no note that many params are action-specific. The unusually self-documenting oneOf schema carries most of that burden, keeping it at minimum-viable rather than inadequate.

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 description adds no information about any of the 36 parameters, not even the required `action` dispatcher. Schema coverage is 69% (below the 80% threshold where a 3 baseline would apply), so the description should compensate for the undocumented quarter but does not; the schema's oneOf blocks do the real work.

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 ('Reads') and resource ('shop data of the active site') and enumerates the nine data domains covered, so an agent knows the breadth of the read surface. The read/write/delete split against shop_write and shop_delete is implied by the verb but not explicitly 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?

The description gives no when-to-use, when-not-to-use, or alternative routing: it never says to use shop_write for mutations or shop_delete for removal. Action selection among the 14 operations is left entirely to the schema's oneOf blocks, not to the description.

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?

Annotations already declare readOnly=false, destructive=true, and openWorld=true. The description adds important domain-specific behavior: no action takes or sends money, payment-method changes may set processing status, order status changes may credit or debit internal shop balances, and no action directly sets a balance. It could also mention confirmation requirements for destructive actions, but that detail is covered in the schema.

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

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

The description is front-loaded with purpose and limited to two sentences with no filler. The second sentence is dense and lengthy, but it carries necessary financial caveats for a destructive shop-write tool.

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

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

Given the rich action schema and annotations, the description supplies the high-level scope and critical financial/balance side effects that would otherwise be missed. It omits explicit routing to shop_read/shop_delete and confirmation guidance, but the schema covers action-specific details and the sibling names provide strong context.

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 description gives no parameter-level meaning beyond listing the shop areas affected. With 80 parameters and only 64% schema description coverage, many arguments rely entirely on schema text, and the description does not compensate for undocumented parameters or explain how action-specific parameters are selected.

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 clear write verbs ('Creates and updates') and enumerates the shop domains covered: categories, products, images, variations, stock, basket, checkout, orders, comments, and currency rates. It is clearly a broad write tool, but it does not explicitly distinguish itself from siblings like shop_read or shop_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?

The opening 'Creates and updates...' implies this tool is for write/edit operations, and the payment caveat clarifies that it does not process real money. However, it never says when to use this versus shop_read for reads or shop_delete for deletions, nor does it flag when to avoid it.

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?

Annotations declare readOnlyHint=false and openWorldHint=true, meaning the agent knows writes/network are involved, but the description never explains that 'install' writes skill files into a filesystem path, what status inspects, or that behavior depends on a remote GitHub repo. The only added context is the select_site prerequisite and the best-effort tracking note (which is already duplicated from the schema). For a multi-mode tool with two unmentioned mutating actions, this is thin.

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 primary purpose front-loaded and zero filler. It loses a point only because compression came at the cost of omitting two of the five actions rather than being deliberately scoped.

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 12 parameters, 5 enum-gated actions, and no output schema, the description should explain each mode. It covers only resolve/catalog/register_usage, leaving status and install (the mutating one) entirely unexplained, so an agent cannot confidently select or invoke those modes from the definition alone.

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 every parameter is already documented in the input schema, including action, scope, client, and skill_id semantics. The description adds nothing beyond that (no mention of repo/ref defaults or limit behavior), 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 and resource ('Looks up official uCoz agent skills') and enumerates three actions, which distinguishes it clearly from the CRUD siblings. However, the schema exposes five actions (resolve, catalog, status, install, register_usage) while the description names only three, so the stated purpose under-describes the tool's actual surface.

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 partial routing cues ('resolve matches a skill to a task description, catalog lists available skills') and one hard prerequisite ('register_usage ... requires select_site'). But there is no guidance on when to choose status vs install, no mention of when this tool should be preferred over docs_tool, and no 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds a reinforcing 'Cannot be undone' warning but goes no further: it does not disclose the approval/confirm gate, the no-refund behavior of cancellation, or what happens to access on cancel — all of which live only in the schema.

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 the destructive operation stated first and the irreversibility caveat second. No waste, though the second sentence largely restates destructiveHint and the first compresses three distinct operations into one 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?

For a 5-parameter destructive tool with three distinct modes and a mandatory confirmation flag, the description is minimally adequate: the schema compensates, but the description never signals the multi-action dispatch or the user-approval prerequisite, which are the two things most likely to cause a bad call.

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%, including per-action requirements and the confirm gate, so the schema carries parameter meaning fully. The description adds nothing beyond it and never references action, confirm, or the id/plan_id distinction; baseline 3 is appropriate.

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 with three enumerated resources ('deletes tariff plans and legacy tariffs, and cancels subscriptions') that map cleanly onto the action enum. It doesn't explicitly contrast itself with sibling tools like subscriptions_write or templates_delete, but an agent can tell it is the destructive member of the subscriptions family.

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 prefer this over alternatives such as subscriptions_write (e.g., downgrade versus cancel) or which of the three actions applies in a given situation. The only contextual statement is the irreversibility warning, which is a hazard note rather than usage routing.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered by structured data. The description's only added context is site-scoped execution, which is genuinely useful. Rate limits, permission requirements and the 30 KB reply cap are left entirely to the schema.

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?

One front-loaded sentence with the resource list immediately after the verb; nothing is wasted or padded. It is arguably too terse for a 12-action tool, but the dimension is about avoiding bloat and this is tight.

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 12-action paginated tool with no output schema, the description should at least signal the action-multiplexing pattern and that paged list replies can be truncated. The exceptionally rich schema and enum descriptions compensate for most of that gap, so this is adequate rather than deficient.

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 `action` enum carries per-operation descriptions listing required and optional parameters, so the schema is doing all the work. The description contributes nothing about the 16 parameters. 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 ("Reads") plus the concrete resources covered: tariff plans, subscriptions, subscribers, access checks and payments, scoped to the Subscriptions module on the active site. That is enough to distinguish it from subscriptions_write/subscriptions_delete. It stops short of saying this is a single multiplexed entry point whose behavior is selected by the `action` enum, which is the tool's defining shape.

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 pick this tool over siblings, no prerequisite about the active site needing to be selected first, and no note that write operations belong to subscriptions_write. The only usage-adjacent phrase is "on the active site," which implies scope but gives no instruction.

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?

Annotations already flag this as destructive and not read-only, and the description adds substantial extra context: no action charges or refunds money on its own, grant/trial/renew/plan change/payment confirm hand out paid access without payment, and auto-renewal can charge the saved card, possibly within the hour, and is silently re-enabled by renew/resume/payment confirm. These are exactly the side effects an agent must know before calling a destructive 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?

Purpose is front-loaded, which is good, but the second sentence is a dense run-on with a nested parenthetical ('...possibly within the hour when the period ends soon (also turned back on by renew, resume and payment confirmation...)') that is hard to parse. Two long sentences for a 16-action tool is defensible in size but poorly structured.

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 26-parameter, 16-action mutation tool with no output schema, the description covers the critical risk surface (no money movement, unpaid access grants, auto-renewal surprises). Per-action parameter requirements are delegated to the schema, which is reasonable, though a pointer to subscriptions_read for lookup and to docs_tool for the fields object would round it out.

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 73% and the oneOf entries already document required/optional fields per action, so the parameter layer is largely self-contained. The description itself adds no syntax or format detail for parameters such as amount, confirm, or the loosely typed price/price_old fields, 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 states a specific set of write verbs and resources: 'Creates and updates tariff plans and subscriptions', then enumerates the operation families (grants, trials, renew, change plan, pause/resume, record/confirm payments). This makes it immediately distinguishable from subscriptions_read and subscriptions_delete without needing 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?

The description implies when each action applies but never states explicit when-to-use/when-not-to-use rules versus alternatives (e.g. read vs write, or docs_tool for extra fields). The per-action preconditions are present, but they live in the schema's oneOf entries rather than in the description, leaving routing guidance implicit.

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?

Annotations already declare destructiveHint=true and readOnlyHint=false, and 'Cannot be undone' largely restates that. The one genuine addition is that this tool also restores a backup over the current templates — a destructive overwrite that a 'delete' tool name would not suggest. No permission, ordering, or approval context is added beyond what annotations and the confirm parameter already cover.

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 tightly-packed sentence with the resource scope front-loaded and the irreversibility warning last. Every clause carries information; the only minor cost is that bundling seven action modes into one sentence makes it dense.

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, seven-action destructive tool the description plus a very rich oneOf schema and destructive annotations gives an agent enough to call it correctly, and no output schema is needed here. What is thin is the operational context: ordering/prerequisites against templates_read and the backup-listing tools, and the fact that 'restore' is not a deletion.

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 every parameter plus each action's required set is documented inline via oneOf, so the schema does the heavy lifting. The description adds no parameter-level meaning (no required-field callout, no id-sourcing hints) beyond what the schema provides. 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 enumerates the exact resource types it acts on (global blocks, menus, mail forms/fields, pages, backups), which is far more informative than the title alone. It also discloses the non-obvious restore behavior. It does not distinguish itself from the many sibling *_delete tools (content_delete, tmaker_delete, etc.), so the boundary of 'site design templates' vs other deletable entities is left 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 explicit when-to-use/when-not guidance and no naming of alternatives such as templates_write or the per-domain delete siblings. The enumeration of deletable entities only weakly implies the usage context, and nothing warns that restore_backup overwrites current templates rather than removing something.

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?

Annotations already declare readOnlyHint, destructiveHint=false and idempotentHint, and "Does not change anything" merely restates that safety profile. No additional behavioral context (pagination/size limits, that validate_template performs no save, that 30 KB list truncation occurs) appears in the description — that detail lives only in the schema.

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, front-loaded with the resource scope and closed with the side-effect guarantee. Nothing is padded and the reader learns the domain in the first 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?

For a sixteen-action multiplexer the description correctly identifies the breadth of coverage, and the oneOf schema entries carry the per-action contracts. What is missing is only the connective guidance (which sibling read tool to prefer, site-selection prerequisite), so it is close to sufficient.

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 description adds no parameter meaning of its own; all sixteen parameters, including the action enum and its per-action requirements, are documented at 100% coverage in the schema. Baseline 3 applies since the schema does all the work.

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?

A specific verb ("Reads") plus a concrete resource set: templates, backups, menus, mail forms, site pages, guides. The enumeration makes the tool's coverage unambiguous and clearly separates it from templates_write/templates_delete. It stops short of differentiating from adjacent read tools such as modules_read or tmaker_read, which also touch design data.

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 the enumeration of resource families; there is no explicit statement of when to pick this over modules_read or tmaker_read, nor any prerequisite (e.g. site must be selected/active). The 'active site' phrase hints at a required context but doesn't state it as a condition.

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?

Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the safety profile is covered. The description adds mutation scope (it writes live design data of the active site) but does not mention the automatic rotated backup, the LIMIT_REACHED refusal, or ALREADY_EXISTS conflicts — those important behavioral details live only in the schema's oneOf entries, not in the description.

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

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

A single front-loaded sentence with no filler, and the resource enumeration is a compact way to convey the tool's breadth. It is slightly list-heavy but every clause maps to a real action family.

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 41-parameter, 15-action multiplexer with no output schema, the description stays minimal because the action enum's oneOf entries do the heavy lifting (required fields, backup behavior, error codes). What is missing from the description itself is a warning that operations act on the currently selected site and that most writes are destructive — but the annotations and schema largely compensate.

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 action enum's oneOf entries document required/optional parameters per action in detail, so the schema carries the burden. The description only contributes the '(full replace or fragment patch)' framing for the two template actions; it does not explain the action multiplexing or the id/gblock_id synonym.

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 pair ('Creates and edits') plus the concrete resources it touches (templates, backups, global blocks, menus, mail forms, pages) and scopes it to the 'active site'. It does not name the sibling tools it competes with (templates_read, templates_delete), so an agent must infer the read/delete split from names 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 only implied: it is clearly the write-side counterpart to templates_read, and the parenthetical '(full replace or fragment patch)' hints at choosing between the two template actions. There is no explicit when-to-use/when-not, no prerequisite (select_site, list_modules) guidance, and no routing advice for the 15 action values.

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?

Annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=false, so the safety profile is known. The description adds nothing beyond that: it does not say the deletion is irreversible, what exactly is removed (project plus its pages/assets?), or how the required confirm flag gates execution.

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, but its brevity reflects under-specification rather than efficiency — nothing is said that the name and title do not already convey.

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 irreversible destructive operation with four parameters (including a numeric/enum indirection between id and project_id), the description omits irreversibility, confirmation semantics, and failure behavior. The rich schema mitigates this, but the description itself is too thin for the risk level.

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%, including the id/project_id synonym relationship and the confirm approval requirement, so the schema does the heavy lifting. The description contributes no additional parameter meaning, making the baseline 3 appropriate.

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 ("Deletes a saved Template Maker project"), but it is essentially a restatement of the title and adds no differentiation from the many sibling delete tools (templates_delete, apps_delete, content_delete, etc.). An agent cannot tell from the description alone how this differs from templates_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?

There is no guidance on when to use this tool versus tmaker_write or templates_delete, and no mention of prerequisites such as needing a project_id from tmaker_read/project_list or user approval before proceeding. The only 'when' information lives in the schema's confirm description, not the tool description.

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?

Annotations already declare destructiveHint=true and openWorldHint=true, so the description isn't carrying the safety burden alone. It still adds real blast-radius context beyond the annotations: all templates are replaced and the entire public site's appearance changes. It does not mention the automatic backup/refusal behavior, but that is documented in the action enum description.

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

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

Two short sentences, zero filler, and the destructive scope is front-loaded before the user-facing consequence. Nothing is repeated from the name or title alone.

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, open-world publish with no output schema, the description covers what is changed and how broadly. The remaining operational details (backup, refusal on backup failure, confirm approval) are fully specified in the schema, so the description is nearly 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% and every parameter (pda, tmpl, action, confirm) is documented in-schema, including the backup-and-refusal semantics and the confirm approval rule. The description adds nothing parameter-specific, 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 and resource: publishes skeleton HTML to the active site and replaces all its templates. The scope ('active site', 'all of its templates') distinguishes it from tmaker_write/templates_write, though it never names those siblings 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 implied rather than stated: the phrase 'Changes the look of the whole public site' signals this is a high-impact, site-wide operation, which helps an agent decide whether to reach for it. There is no explicit when-to-use/when-not or reference to tmaker_write versus this publish step, and the confirm-gating workflow appears only in the schema.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered elsewhere. The only extra behavioral note is that skeleton validation does not persist anything ('without saving it'), but that same fact is already stated in the schema's skeleton_validate entry, so the description adds little beyond structured fields.

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; the resource enumeration comes first and the validation caveat second. It is efficient, though it could have traded one clause for an explicit routing hint to the write/delete siblings.

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 100% schema coverage, an output-schema-free design, and annotations covering read-only/idempotency, the description is nearly complete for a multi-action read tool. The remaining gap is routing guidance to sibling mutation tools and pagination behavior, both of which are only partly addressed elsewhere.

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 action enum documents each operation along with its required id/tmpl/offset parameters. The description names the data categories but supplies no syntax, defaults, or id-source detail beyond what the schema already gives, 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 names a specific verb (reads) plus the concrete resource groups it exposes: skeleton guide, placeholder rules, standard designs, saved projects, and skeleton validation. An agent can distinguish it from tmaker_write/tmaker_delete/tmaker_publish by the read/validate framing, though it never explicitly names those siblings.

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