uCoz

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

With no annotations, the description carries the full burden and does it well: it discloses confirm:true requirements for a concrete list of destructive actions, that login key 'main' is stored but omitted from responses, that SQL export/import returns a phpMyAdmin link rather than a dump, and that large/binary files return a public URL instead of bytes. Remaining gaps (rate limits, per-action side effects) are minor against how much non-obvious behavior is already surfaced.

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?

Dense and telegraphic, but nearly every clause carries a distinct constraint (path rules, download link domain, MySQL prefixing, confirm list) rather than filler. Front-loading the scope and sibling exclusions before the caveat pile-up is the right structure; the fragment style is terse but hard to scan.

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 58-parameter, 95-action tool with no annotations and no output schema, the description covers setup order, path semantics, response quirks, and destructive-action gating, and points to get_guide for the rest. Given the complexity, it is complete enough to call safely, though per-action return behavior is necessarily 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 is unusually detailed, so the baseline is 3. The description's parameter notes ('FTP create uses type=ftp', 'Cron delete uses select0', path-prefix rules) largely restate what the schema already encodes in select0/cron_id/name 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 states a specific domain (server scripts environment on the selected site) and explicitly rules out the three nearest siblings: modules_tool, files_tool, and ftp_tool. What holds it below 5 is the sheer breadth – 95 enum actions spanning uAPI, DirectAdmin env, MySQL, files, cron, FTP, Node/Python – so 'what it does' is clear as a category but diffuse as a single verb+resource.

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?

Provides real sequencing guidance ('call select_site first', 'Order: get_guide, status, ensure_ready') and predicates prerequisites on user approval. It does not give per-action when-to-use guidance for the 95 operations, but the get_guide pointer and the confirm gating cover the main routing decisions.

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

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

With no annotations, the description carries the full burden and usefully discloses non-obvious behaviors: first-login activation, automatic selection for the MCP session, and that it does not replace the Control Panel. However, it still omits permission requirements, error cases, and whether creation is reversible or how it affects existing sites.

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 with no filler: the first front-loads the action and side effects, and the second adds a relevant limitation. Every sentence earns its place.

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

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

For a creation tool with full parameter schema coverage but no annotations or output schema, the description covers the core operation and key side effects. It is nearly complete, though it could mention auth scope details or failure behavior.

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

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

Schema coverage is 100%, so the schema already documents all three parameters, including the enum mapping for dom and the format for addr. The description adds no additional parameter meaning, which is acceptable given full schema coverage.

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 (Create) and resource (site), and it also names two important side effects: first-login activation and session selection. This distinguishes it from siblings like select_site and list_sites without needing their schemas.

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 the tool is for creating a new site under the authorized account, but it does not explicitly state when to use it versus alternatives such as select_site or list_sites. The note about the Control Panel flow is contextual, not a usage guideline.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does add real context: this is a fallback source, it needs no select_site, and each action maps to a scope of output (catalog vs fragments vs full spec). However it says nothing about read-only nature, caching, rate limits, or response size for full spec fetches, which is material for a fetch-heavy tool.

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

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

Three short, front-loaded sentences: the resource and location first, then the fallback routing rule, then the action glossary. Dense but every clause earns its place. The telegraphic style ('… schemas', 'list — catalog') is terse but 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 5-parameter lookup tool with no output schema and full schema coverage, the description supplies the routing context (when it is the right tool) and the action semantics an agent needs. Absent only secondary detail like caching or response size, which is not required to call it correctly.

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

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

Schema coverage is 100%, so every parameter (url, limit, query, action, module) is already documented in the schema, including the action enum semantics and the module examples. The description restates the action breakdown rather than adding syntax, format, or edge-case meaning beyond it. 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 resource (the OpenAPI YAML reference at api.ucoz.net/{module}-openapi.yaml) and frames it as a fallback, distinguishing it from the primary content_tool/users_tool/shop_tool schemas. The three action verbs (list/search/fetch_spec) are enumerated, so an agent knows what it can do. It stops short of a single crisp verb+resource statement, but purpose is clearly inferable.

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 an explicit when-to-use condition ('Use only when a rare uAPI key is missing from content_tool / users_tool / shop_tool / … schemas'), which is the strongest form of routing guidance available. It also adds a prerequisite note ('Does not require select_site'), useful given select_site is a sibling tool. It lacks explicit when-not-to-use beyond the fallback framing, so not 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?

With no annotations, the description carries the full burden and does so well: it discloses the required authorization ('Requires CP access on the site API key (can_use_cp)'), the upstream endpoint that is proxied, and a critical output trait ('the response may include ftp_password in plain text — save it immediately'). The sensitive-return warning is exactly the kind of context structured fields cannot convey.

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?

Dense but front-loaded: purpose first, then routing, then auth, then the plain-text warning. Each sentence carries distinct information with no filler, though the run-on nature of the first sentence slightly reduces readability.

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 4-parameter mutation tool with no annotations and no output schema, the description covers prerequisite ordering, authorization, the upstream proxy target, sibling routing, and return-value handling. An agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so each of the four parameters (including the enum and the password synonym) is already documented. The description reinforces the action semantics and notes the plain-text return for set/change, but adds no syntax or format detail beyond the schema. 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?

States a specific resource and scope ('FTP password management on the selected site') rather than restating the tool name. It explicitly distinguishes itself from siblings by declaring that files_tool, not this tool, handles file FTP operations. An agent can place it against files_tool and select_site without opening any 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 an explicit prerequisite ('call select_site first') and a clear negative route ('Account MCP does not run file FTP... use files_tool'). The action mapping (set=POST when unset, change=PUT when set, reset=DELETE with confirmation) tells the agent exactly when each mode applies. Nothing is left to inference.

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

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

No annotations exist, so the description carries the full disclosure burden. Beyond implying an authorization requirement via 'authorized account (GUID)', it says nothing about result size, pagination, ordering, or whether the call has side effects.

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

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

A single front-loaded sentence with no filler. It is appropriately sized for the operation, though it is minimal enough that it could have carried one more clause of useful context at no cost to clarity.

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

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

For a zero-parameter listing tool with no output schema, the description is minimally adequate but leaves the return shape, scope limits, and result volume unstated. Nothing here would cause a wrong invocation, but an agent knows little about what it will get back.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. The baseline for a parameterless tool applies.

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 ('List') plus resource ('sites') and narrows scope to the authorized account, so the purpose is unambiguous. It does not distinguish itself from near-siblings such as select_site or create_site, which is the only gap.

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 versus select_site or create_site, nor any stated prerequisite beyond 'authorized'. The agent must infer usage entirely from the name.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the auth architecture (server-minted Bearer key, 'the client never sees sk_live'), which is genuine context beyond the schema. However, it does not characterize which actions are destructive (uninstall, disable), what they affect, or rate/permission constraints, leaving the mutating behaviors underspecified.

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

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

Two tight sentences with the prerequisite front-loaded and the security note appended. Every clause carries information; nothing is redundant 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 9-action tool with no annotations and no output schema, the description leans heavily on the enum descriptions to convey per-action behavior. It covers hosting/auth context but omits which actions are read-only versus mutating and what each returns, so it is adequate rather than 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 all three parameters are thoroughly documented in the schema itself, including the per-action endpoint mapping and the confirm/module_code requirements. The description adds the select_site sequencing, but otherwise repeats the schema's burden; 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?

States the resource ('Site modules') and scope ('on the currently selected site'), plus a prerequisite. It is clear what the tool operates on, but the verb is weak (the noun 'modules' is used as an action) and it does not differentiate itself from siblings such as templates_tool or content_tool beyond the word 'modules'.

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

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

Explicitly says 'call select_site first', establishing a hard prerequisite, and the module_code parameter tells the agent to source identifiers from modules_list or active_mods rather than guessing. It does not say when to prefer this tool over siblings, but for a multi-action admin tool the context is clear.

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

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

With no annotations, the description carries the full burden. It adds meaningful context by scoping the selection 'for this authorization' and describing it as setting a 'current' state, hinting at session-scoped persistence. It says nothing about overwriting a prior selection, validation failures, or permissions, so it is only partially adequate for a stateful mutation.

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 sentence, front-loaded with the verb and the outcome, with no filler. It is appropriately sized, though it has room to add one clause of behavioral detail without becoming bloated.

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 stateful tool with no annotations and no output schema, the description covers purpose and scope but omits behavior on repeat calls, failure modes, and whether any confirmation is returned. Adequate as a minimum viable definition but with clear gaps.

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

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

Schema coverage is 100% for the single site_id parameter, so the schema already carries the semantics and the baseline is 3. The description restates that the site comes from list_sites, which duplicates rather than extends the schema's own 'Numeric site id from list_sites'.

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 action ('Remember a site ... as the current site'), naming the resource and the resulting state, which separates it from create_site (creates) and list_sites (enumerates). It does not explicitly name those siblings, so it falls short of the 5 bar.

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 reference to list_sites implies the intended workflow (pick an id from that tool, then select it), which is useful implied guidance. However, it never states when this should be called versus other tools, whether a site must already be selected, or what happens if it is called twice.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the transport ('Proxies to /uapi/subscriptions/* with a server-minted Bearer key'), implying auth is handled for the caller. However, for a tool with destructive actions (plan_delete, subscription_cancel, payment_refund), it does not itself explain mutation/reversibility semantics beyond what the schema's action/confirm descriptions already say.

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?

Four dense sentences that are front-loaded with the module identity and scope. Every sentence carries routing, prerequisite, or transport information with no filler. Slightly more information density than strictly necessary but well-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 high-complexity 33-action tool with no output schema, the description covers scope, prerequisites, and transport but does not explain return shapes or how to navigate the action surface. The essentials for correct invocation (select_site, modules_tool, confirm) are present, but the coverage feels thin relative to the surface area.

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 79%, so the schema already documents most of the 33 parameters, including enums for action and type. The description adds no parameter-level syntax or format detail beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description names the resource domain precisely (subscriptions module) and enumerates its functional areas: tariff plans, user subscriptions, access checks, and payments. It explicitly excludes siblings ('Not shop_tool, users_tool, or content_tool'), so an agent can place it against alternatives. It stops short of 5 because the tool is a 33-action mega-tool and the description gives no per-action verb precision.

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 states a concrete prerequisite ('call select_site first') and an install gate ('Module must be installed via modules_tool'), plus negative routing against three siblings. This is clear when-to-use and when-not-to-use context. It lacks guidance on choosing among the 33 actions, which keeps it from 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?

With no annotations, the description carries the full burden, and it does add real context: the tool proxies to /uapi/users/* under a server-minted Bearer key, implying delegated auth. However it says nothing about the destructive actions (delete, group_delete, chpass) or the approval/confirm requirement, which is the most important behavioral fact for this tool.

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

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

Two dense sentences with the prerequisite front-loaded and no filler. The telegraphic action list ('List/profiles, groups, ranks, chlogin/chgroup/chpass') is compact but slightly cryptic without the schema in hand.

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-parameter, nested-object, no-output-schema tool, the definition covers site prerequisite and auth path but omits the destructive-action/confirm flow, pagination via page, and the distinction between ranks/fields metadata and group permissions.

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

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

Schema description coverage is 100% and the action enum documents routing per action, so the baseline is 3. The description's 'List/profiles, groups, ranks, chlogin/chgroup/chpass' loosely maps to action families but adds 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?

It names the resource (site users module) and scopes it to the currently selected site, then enumerates the functional families it covers: profiles, groups, ranks, chlogin/chgroup/chpass. That is more than a restated name, though it is a multi-action router rather than a single verb+resource, and it never contrasts with any sibling.

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 parenthetical '(call select_site first)' gives an explicit hard prerequisite that the agent must satisfy before invoking. There are no competing user-management siblings to disambiguate against and no when-not guidance, but the sequencing context is stated concretely.

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