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 discloses only that the account password is the credential; it says nothing about whether disabling invalidates existing recovery codes or sessions, whether the change is reversible, whether it requires elevated auth, or what the response contains — significant gaps for a security-weakening 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 front-loaded sentence with no filler, correctly leading with the action. It is efficient, though its brevity leaves no room for the risk context that a destructive security operation warrants.

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?

Five parameters with panel/URL/key overrides, no output schema, and no annotations — yet the description mentions none of the environment-override mechanics and none of the effects. For a security-critical mutation it should explain consequences and return behavior; here almost everything must be inferred.

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 80%, so the schema already documents panel, baseUrl, clientKey, and applicationKey. The description's only added parameter content is that the password gates the operation, which is already implied by the required field. Baseline 3 applies.

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

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

States a specific verb+resource ('Disable two-factor authentication') plus the credential it needs. The name and description together clearly distinguish it from account_2fa_enable and account_2fa_get, though the description itself never 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.

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

No guidance on when an agent should call this versus account_2fa_get or account_update_password, no prerequisites beyond the password parameter, and no warning about the security consequence of turning 2FA off. The agent is left to infer usage entirely.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully says recovery tokens are returned, but it omits auth/permission requirements, what happens if 2FA is already enabled, and whether recovery tokens are shown once or persisted.

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 operation and mechanism, and the return-value note is also concise. There is no wasted text.

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 description is adequate to invoke the tool: the required TOTP code is clear, and the return of recovery tokens is disclosed despite no output schema. However, for a security-sensitive mutation with no annotations, it omits prerequisites and permission context, leaving clear gaps.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the input schema. The description mentions the TOTP code, which aligns with the required parameter, but adds no meaningful detail for the panel, baseUrl, clientKey, or applicationKey overrides, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: enabling two-factor authentication. It adds the confirmation mechanism ('by confirming a TOTP code') and the return value ('recovery tokens'), which clearly separates it from sibling tools like account_2fa_get and account_2fa_disable.

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 explains the mechanism but gives no explicit when-to-use guidance, prerequisites, or alternatives. It does not say when to use this instead of account_2fa_get or account_2fa_disable, nor whether 2FA setup must happen first.

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, yet it says nothing about whether the returned secret is single-use or invalidated by repeated calls, whether the account must not already have 2FA enabled, or that the secret must be confirmed via account_2fa_enable. For a read that exposes a credential, this silence is a meaningful gap.

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 returns the resource description immediately, with zero filler. There is little structure to evaluate because the description is so short.

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

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

With no annotations and no output schema, the description is the only source for the enrollment contract, and it only obliquely covers the return shape (secret plus QR URL). It omits the lifecycle relationship to account_2fa_enable, which is the missing piece for an agent to use this 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% with all four parameters (panel, baseUrl, clientKey, applicationKey) fully documented inline, so the baseline is 3. The description adds nothing about panel/credential override resolution, which is acceptable given the schema already handles it.

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

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

The description names a specific verb ('Get') and the exact resource returned ('TOTP secret / QR image URL'), which distinguishes it from the sibling mutations account_2fa_enable and account_2fa_disable. It stops short of explicitly naming those siblings as the follow-up/alternative steps.

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

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

The phrase 'to enable two-factor authentication' implies this is the first step of the 2FA enrollment flow, but the tool never states when it should be called versus account_2fa_enable / account_2fa_disable, nor what to do if 2FA is already active. Usage is only inferable from context.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it only implies a safe read operation via 'Get'. It says nothing about pagination behavior, default page size, whether results are complete or truncated, or the permissions/auth context (panel, clientKey, applicationKey overrides) needed to call it successfully.

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 short sentence with no filler, so it is not verbose, but it is under-specified rather than genuinely concise. There is no structure to front-load because there is only a bare purpose statement.

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

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

This is a 9-parameter tool with no annotations and no output schema, including non-trivial overrides (panel, baseUrl, clientKey, applicationKey) that are not mentioned anywhere. Given that complexity, a single-sentence description leaves an agent without enough context to invoke it correctly or interpret its results.

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 78% but the description contributes zero parameter meaning — it never mentions filtering by event, sorting, pagination, or the include option. Notably 'page' has no schema description at all and 'include' is only documented as 'e.g. actor', so the description leaves real ambiguity (e.g. what include values are valid) unaddressed.

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 retrieval verb and the resource ('account activity log'), and the word 'account' implies account-level scope as opposed to the sibling server_activity. However, it adds nothing beyond the title 'Account activity log' other than 'Get', and gives no hint about what the log contains or how it differs from server_activity beyond scope.

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 server_activity, or on prerequisites like which panel or API key context is required. The agent must infer everything from the name alone.

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

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

With no annotations at all, the description carries the full disclosure burden, and it does deliver one genuinely critical trait: 'The secret is only returned once', which tells the agent to capture the value immediately. It omits other relevant behavior for a mutation tool — required permissions, whether keys expire or are revocable, and that the inline panel/baseUrl/clientKey/applicationKey values are overrides rather than persisted settings.

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

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

Two short sentences, zero filler, with the core action first and the critical once-only secret caveat immediately after. Nothing is padded or repeated from the schema.

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

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

For a 6-parameter creation tool with no annotations and no output schema, the definition covers the action and the most important consequence (single-return secret) but not what the response contains, what permissions are needed, or how the optional override parameters interact with saved panels. Adequate but with clear gaps.

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

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

Schema description coverage is 83%, so the schema already explains panel, baseUrl, clientKey, applicationKey and allowed_ips. The description adds no parameter-level detail beyond the word 'client', and notably leaves the required 'description' parameter undocumented in both places. 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 ('Create a new client API key'), which cleanly separates it from account_apikey_list and account_apikey_delete in the sibling set. It does not explicitly contrast the 'client' key with the applicationKey override, but the core purpose is unambiguous.

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

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

There is no statement of when to create a key versus listing or deleting one, no prerequisites (e.g. needing panel authentication or an application key first), and no mention of scope or limits. 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?

With no annotations provided, the description carries the full disclosure burden, yet it only implies destruction via "Revoke." It does not say whether the key is hard-deleted or disabled, whether permission scoping is required, or what happens to active sessions using that key.

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 or redundancy. It is efficiently structured, though the terseness leaves room for one or two more high-value sentences.

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

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

A destructive credential-revocation tool with no annotations and no output schema needs to spell out irreversibility and side effects. The description covers only the basic action, leaving the agent without the safety context this operation demands.

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 80%; the connection-override parameters (panel, baseUrl, clientKey, applicationKey) are already documented in the schema. The description only confirms that `identifier` is the target selector, which the required-fields list already signals, so it adds little beyond structured data.

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 ("Revoke") plus resource ("client API key") plus the lookup key ("by its identifier") clearly separate it from account_apikey_list and account_apikey_create. It stops short of stating whether application keys (ptla_) are also covered, so it is clear but not airtight.

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

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

No indication of when to use this versus listing keys first, no prerequisites, and no note that revocation is irreversible or affects clients currently authenticating with the key. The agent must infer all usage context from the name alone.

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

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

No annotations are provided, so the description must carry the behavioral burden: it does disclose scope (client keys only, not application keys), which is useful context beyond the schema. However, it says nothing about whether key secrets/full key values are returned, whether results are paginated, or what auth/panel context is required — meaningful gaps for a credentials-listing tool with zero annotation coverage.

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

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

A single seven-word sentence with no padding, and the resource plus scope qualifier are front-loaded. It is efficient, though the brevity contributes to the completeness gaps elsewhere.

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 need not explain return values, and parameter semantics are covered by the schema. Still, for a tool listing account credentials it leaves open whether secrets are exposed and how the panel/override parameters interact with the listing, which an agent would want to know before calling.

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 each of the four optional parameters (panel, baseUrl, clientKey, applicationKey) is documented as an inline override or saved-panel selector. The description adds nothing about how these overrides affect the listing, so the baseline 3 applies.

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

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

The description gives a specific verb and resource ("List the account's ... API keys") and narrows scope to client keys, which separates it from the create/delete siblings. It doesn't explain the client-vs-application key distinction explicitly, but the qualifier is still doing differentiating work.

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

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

There is no statement of when to use this versus account_apikey_create, account_apikey_delete, or how to obtain application keys. The verb "List" implies a read operation, but no alternatives, prerequisites, or exclusions are named.

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

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

No annotations are provided, so the description carries the full burden. 'Get' implies a read, but it discloses nothing about the auth mechanisms hinted at by the clientKey/applicationKey params, what details are returned, or how failures (invalid panel/key) manifest.

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

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

A single front-loaded sentence with zero waste. It is appropriately sized for the operation, though its brevity borders on under-specification rather than elegant economy.

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, no annotations, and the description never indicates what account fields come back or what the panel/baseUrl/clientKey overrides do to the result. For a read-details tool whose return value matters, this leaves a moderate gap.

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?

All four parameters have full schema descriptions (100% coverage), including the panel vs. inline-override distinction, so the schema does the heavy lifting. The description adds nothing about parameters, which is acceptable at this coverage but not additive.

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 (get) and resource (authenticated user's account details), which is clear and distinct from mutating siblings like account_update_email. It does not explicitly differentiate itself from account_activity or account_2fa_get, but the resource scope is unambiguous.

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

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

Usage is only implied: needing the current account's profile. There is no stated when-not, no mention of alternatives like account_activity or account_2fa_get, and no prerequisites beyond the phrase 'authenticated user's'.

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 conveys only that a key is added, saying nothing about duplicate-key handling, idempotency, required permissions, or what happens to the override params (panel, clientKey, applicationKey) — a meaningful gap for a write tool with zero annotation coverage.

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

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

A single front-loaded sentence with no waste. It is concise and readable, though the brevity edges toward under-specification rather than deliberate economy.

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 mutation tool with no annotations and no output schema, the description is too thin. It omits the meaning of the required name/public_key parameters and the purpose of the auth-override params, leaving the agent to reconstruct behavior 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 coverage is 67%: panel, baseUrl, clientKey, and applicationKey are documented in the schema, but the two required params (name, public_key) have no descriptions in either schema or description. The description names the 'public key' concept but adds no format or constraints, so it neither compensates for the required-param gap nor adds value beyond the schema.

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

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

States a specific verb ('Add') and resource ('SSH public key to the account'), clearly distinguishing it from account_sshkey_list and account_sshkey_remove by the mutation verb. It lacks any explicit sibling routing but the name and description together make the purpose unambiguous.

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

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

No guidance on when to use this versus account_sshkey_remove or account_sshkey_list, and no prerequisites or exclusions are stated. The agent must infer all usage context from the name alone.

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

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

No annotations are provided, so the description carries the full burden, and it discloses almost nothing: not whether the operation is read-only (implied by 'List' but not stated), whether private key material is exposed, whether results are paginated, or whether panel/auth overrides are validated. 'List' is the only behavioral signal.

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

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

A single short sentence, front-loaded with the action and scope, with no filler. It is efficient, though the terseness borders on under-specification handled elsewhere.

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

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

With no annotations, no output schema, and four auth/panel-override parameters, the description should at least note what is returned (e.g., key fingerprints vs. private material) and the auth-override behavior. For a tool this simple it is close to adequate, but the absence of any behavioral or return context leaves real gaps.

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

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

Schema description coverage is 100%, so the four parameters (panel, baseUrl, clientKey, applicationKey) are already documented in the schema. The description adds no extra 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?

States a specific verb ('List') and resource ('the account's SSH keys'), which is unambiguous. It does not explicitly differentiate itself from siblings account_sshkey_create and account_sshkey_remove, but the verb does the work implicitly.

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

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

No guidance on when to use this versus other account tools, no prerequisites, and no mention of what it does not cover (create/remove). The agent must infer everything from the name.

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

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

No annotations are provided, so the description carries the full burden. It implies deletion but never says the removal is irreversible, what happens to servers still authorized by that key, or whether the fingerprint must match exactly. For a mutation with zero annotation coverage this is a real gap.

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 identifying parameter placed where it matters. It is efficient, though the brevity reflects under-specification rather than true completeness.

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

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

A destructive account-level mutation with no annotations and no output schema should explain irreversibility and the practical workflow (look up key, then remove). The description supplies neither, so an agent lacks what it needs beyond the raw 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 80%, so the schema already documents the panel, baseUrl, clientKey and applicationKey overrides. The description adds only 'by fingerprint', which confirms the selector role of the required field but nothing about format or matching semantics. 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 ('Remove an SSH key from the account') and adds the identifying mechanism ('by fingerprint'), which clearly separates it from account_sshkey_list and account_sshkey_create. It never names a sibling explicitly, so it stops short of the 5 band.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the alternative (e.g. how to first discover a fingerprint via account_sshkey_list). The agent must infer everything from the tool name.

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

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

With no annotations, the description must carry the full burden. It usefully discloses the credential requirement, but says nothing about side effects an agent would care about: whether changing email invalidates sessions or API keys, whether verification is triggered, or whether the change is immediate.

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

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

Two short sentences with zero filler, and the auth prerequisite is front-loaded right after the action. The terseness borders on under-specification rather than waste, but nothing written 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 six-parameter mutation tool with no annotations and no output schema, the description covers the action and the credential prerequisite but leaves side effects, failure modes, and the panel/key override params unexplained. Adequate to attempt a call, not complete.

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

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

Schema coverage is 67%; the description touches only email and password, both of which the schema already marks as required. It adds no format, constraint, or meaning for the four undocumented connection-override params (panel, baseUrl, clientKey, applicationKey), though those are largely self-explanatory in schema.

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

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

States a specific verb+resource ('Change the account email') that an agent can immediately distinguish from account_update_password and other account_* siblings. It does not explicitly name the nearest sibling, so it falls just short of 5.

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

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

The prerequisite 'Requires the current password' is a real usage condition, but there is no guidance on when to choose this over account_update_password or what to do if the password isn't known. Usage is implied from the name rather than spelled out.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does not say this is an irreversible mutation, whether the current session survives, what authentication is required, or what the result looks like.

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 waste, but it is under-specified for a seven-parameter mutation tool. Conciseness here comes at the cost of necessary information.

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

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

A mutation tool with no annotations, no output schema, seven parameters, and only 57% schema coverage needs more than five words. The description lacks authentication, confirmation, and irreversibility 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?

Schema description coverage is 57%; the required password fields (current_password, password, password_confirmation) have no schema descriptions and the description does not compensate. The agent is left to infer that password_confirmation must match.

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 ('Change') and resource ('account password'), so the agent knows this is a password-mutation tool. It is close to the title but adds the account scope; there is no sibling differentiation, though sibling account_update_email covers a different 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?

No guidance on when to use this versus account_apikey_create or account_update_email, and no prerequisites. The description does not mention that the current password is required or that the new password must be confirmed.

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

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

With no annotations, the description carries the full behavioral burden but only clarifies one parameter. It does not say whether the backup is synchronous or async, how long it takes, whether it is destructive to existing backups, or whether permissions are required — significant gaps for a mutation tool.

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

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

Two short sentences, front-loaded with the core purpose, and the second sentence is targeted at the one parameter that genuinely needs clarification. No wasted text.

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

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

An 8-parameter mutation tool with no annotations, no output schema, and half the schema descriptions missing. The description addresses only one parameter and none of the runtime behavior, so it is well short of what an agent needs to invoke this confidently.

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 50%, and the description usefully explains the 'ignored' parameter's format (newline-separated glob patterns) where the schema provides no description at all. However, 7 other parameters — including required 'server', 'name', 'is_locked', and the inline credential overrides — get no mention in the description, so it only partially compensates.

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 ('Start a new backup'), which unambiguously separates it from backup_list, backup_restore, and backup_delete. It doesn't explicitly name a contrasting sibling, but the operation is self-evident from the phrasing.

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

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

No guidance on when to use this versus alternatives, and no prerequisites such as whether the server must be online, whether it counts against a backup limit, or what happens if a backup is already running. Usage must be inferred entirely from the name.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure and fails to meet it: it does not say the deletion is irreversible, whether backups must be unlocked first, what permissions/keys are required, or what happens on success. For an irreversible mutation this is a significant gap.

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

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

A single short sentence with the action front-loaded and no filler. It is efficient, though its brevity is under-specification rather than deliberate density.

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, unannotated tool with six parameters, 67% schema coverage, no output schema, and undescribed required identifiers, the description should explain permanence, prerequisites, and parameter meaning. None of that is present.

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

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

Schema coverage is only 67%, and the two required parameters (server, backup) have no schema descriptions at all — the description likewise adds nothing about whether "backup" is a name, UUID, or index, or how it relates to the server. Only the panel/baseUrl/key overrides are documented, and only by 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 states a specific verb and resource ("Delete a backup"), which is clearer than the title alone, but it does nothing to distinguish this from siblings like backup_restore, backup_toggle_lock, or backup_get — the agent must infer that this is the destructive 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?

There is no guidance on when to use this versus backup_restore or backup_toggle_lock, no mention of prerequisites such as whether a locked backup must be unlocked first, and no exclusions. The agent gets an implied destructive intent from the name only.

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

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

With no annotations, the description carries the full burden, and it does disclose one important trait: the URL is one-time signed, implying single-use/expiring credentials. It does not say how long the URL lasts, whether generating it consumes/locks anything, or what auth is required for the panel/API-key overrides.

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, both front-loaded and free of filler; the result-handling hint follows the purpose statement in the right order. 'Outside the model context' is slightly jargon-y but not wasteful.

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 tool whose entire output is a URL, the description never says what the response looks like (raw URL string vs. an object field), and there is no output schema to fall back on. With 6 parameters, no annotations, and two undescribed required params, the description leaves material gaps for correct invocation.

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

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

Schema coverage is 67%, and the two required parameters (server, backup) have no descriptions in either the schema or the description. The description says nothing about what 'backup' identifies or how 'server' relates to 'panel'. The undocumented required fields are exactly the ones an agent must supply.

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: returns a one-time signed URL to download a backup. An agent can distinguish it from backup_get (metadata) and files_download_url (files). However it does not explicitly name or contrast with those siblings, so it stays 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?

'Fetch it outside the model context' is a usable operating instruction for what to do with the result, which implies the intended workflow. But there is no explicit statement of when to choose this over backup_get or backup_restore, nor any prerequisite (e.g. backup must exist, must be unlocked).

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 implies a read-only fetch but says nothing about behavior if the backup or server does not exist, permission requirements, or what fields 'details' includes. For a tool with zero annotation coverage this is a substantial gap.

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

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

A single short sentence with no waste, but its brevity comes from under-specification rather than efficiency.

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

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

No output schema exists, so the description should explain what a 'details' response contains and how the panel/override parameters interact. It does neither, leaving an agent to guess at the result shape and auth override 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?

With 6 parameters and only 67% schema description coverage, the description adds no parameter meaning at all. The two required parameters, 'server' and 'backup', are undocumented in both schema and description, so the agent gets no help on their expected format.

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 'get' and resource 'backup' plus 'one backup' distinguish it slightly from backup_list, but the description never names that sibling or specifies what 'details' means. It is a minimal but readable statement of purpose.

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

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

No when-to-use guidance, no mention of prerequisites, and no explicit contrast with backup_list (which retrieves many) or backup_restore/backup_download_url (which act on a backup). The agent must infer everything from the name.

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

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

No annotations are provided, so the description carries the full behavioral burden. It only says 'List' and does not disclose pagination behavior, ordering, permission requirements, or what happens when backups are locked or absent.

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 wasted words. Its brevity is structurally clean, though it leaves important context to other dimensions.

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

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

For a 7-parameter tool with no annotations and no output schema, one sentence is not enough. The description omits pagination, filtering, panel selection, and return-value expectations that an agent would need to invoke it confidently.

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

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

The schema has 7 parameters with only 57% description coverage, and the description adds meaning only for the 'server' parameter implicitly. It does not explain page, perPage, panel, or the inline credential/URL overrides.

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 essentially restates the tool name and title: 'backup_list' / 'List backups' becomes 'List the server's backups.' It adds the server scoping but does not differentiate the tool from siblings like backup_get or backup_download_url beyond the verb 'List.'

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 backup_get, backup_download_url, or other sibling backup tools. It also does not mention prerequisites such as needing a server identifier or panel context.

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

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

With no annotations, the description carries the full burden. It does disclose one genuinely important behavioral trait — that 'truncate wipes existing files first' — which signals destructiveness. However, it never says that a plain restore also overwrites existing server files, nor does it mention required permissions, whether the server is stopped/restarted, or whether the action is recoverable.

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 primary action and followed by the key destructive caveat. No wasted words, though the lowercase fragment 'truncate wipes...' reads as a note rather than structured guidance.

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 mutation with 7 parameters, no annotations, no output schema, and 43% undocumented parameter coverage, the description is materially incomplete. It omits overwrite semantics for non-truncate restores, prerequisites, and any post-restore state information the agent would need to call this safely.

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 57%, so several parameters (backup, server, truncate) are undocumented in the schema. The description explains the effect of `truncate` behaviorally ('wipes existing files first'), which is useful, but leaves `backup` and `server` (e.g., identifier format) unexplained. Baseline 3 is appropriate for the partial 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 and resource ('Restore a backup to the server') and is clearly distinct from siblings like backup_create, backup_list, and backup_download_url. It doesn't explicitly call out those siblings, but the operation is unambiguous.

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

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

There is no guidance on when to use this versus alternatives, no preconditions (e.g., backup must exist, server state, whether the server should be stopped), and no warning that restore overwrites live server files. The agent is left to infer everything about appropriateness.

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

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

With no annotations, the description carries the full burden, and it does disclose the meaningful behavioral consequence of locking (blocks deletion and rotation). However, it omits toggle semantics — whether the call inverts current state, is idempotent, or what it returns — and says nothing about required permissions or reversibility of the unlock direction.

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 core action first and the consequence in a parenthetical — no wasted words. It is terse enough that it could afford one more clause on toggle behavior 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?

This is a mutation with no annotations, no output schema, and six parameters, including four auth/panel override params. The description never resolves the central ambiguity of a toggle-style tool (no desired-state parameter) nor states what happens on repeat invocation, leaving a meaningful gap for an agent about to mutate backup state.

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 67%, and the description names no parameters at all; the two required parameters (server, backup) have no schema descriptions, so an agent must infer that they identify the target backup and its owning server. Panel/baseUrl/clientKey/applicationKey are documented in the schema, so the description's silence there is acceptable.

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

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

States a specific verb pair (lock/unlock) and resource (backup), and adds the consequence that locked backups cannot be deleted or rotated out, which makes the effect tangible. It does not explicitly differentiate itself from backup_delete/backup_restore, but the action is distinctive enough that an agent can identify it.

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

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

No guidance on when to lock versus leave unlocked, no prerequisites (permissions, backup state), and no mention of alternatives. Since there is no target-state parameter, an agent gets no hint that this flips the current state rather than setting an explicit lock value.

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 supplied, so the description carries the full behavioral burden and largely drops it. It does not say what happens on a name collision, whether the operation returns credentials, what permissions or panel/API keys are required, or how the inline baseUrl/clientKey/applicationKey overrides interact with persistence beyond what the schema already states.

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 short sentence, front-loaded and free of waste, but it is under-specified rather than genuinely concise — the brevity comes at the cost of any useful information.

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

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

For a mutation tool with 7 parameters, no annotations, and no output schema, the description is far too thin. It never explains server identification, panel selection versus inline overrides, or what the caller receives after creation — all things an agent needs before invoking it.

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 86%, so most parameters are already documented (panel, remote, baseUrl, database, clientKey, applicationKey). The description adds nothing to explain 'server' (the only undocumented param, likely an identifier) or how required server/database relate. Baseline 3 applies when the schema does 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 states a verb and resource (create a database) and adds minimal scope ('on the server'), but it essentially restates the tool name db_create and the title 'Create a database'. It does nothing to distinguish this from sibling tools like db_list, db_delete, or db_rotate_password, so the agent gets no differentiating detail.

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

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

There is no when-to-use guidance, no preconditions, and no mention of alternatives such as db_list for checking existing databases or db_rotate_password for credential management. The agent must infer the tool's role from the name alone.

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

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

No annotations are provided, so the description carries the full burden of disclosure. It states that a deletion occurs but says nothing about irreversibility, required permissions, or the effect on related resources, which is a significant omission for a destructive 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?

The single sentence is short and front-loaded, but it is under-specified rather than genuinely concise. It avoids bloat but fails to include information that would make the tool easier to invoke correctly.

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 no annotations, no output schema, and six parameters (two required and undocumented), the description is too thin. It leaves out safety, permission, and parameter details that an agent needs before calling it.

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 67%, but the two required parameters ('server' and 'database') have no descriptions in either the schema or the tool description. The description adds no semantic meaning beyond the bare parameter names already present in 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 gives a specific verb and resource ('Delete a database'), and the tool name makes it distinguishable from sibling tools like db_create, db_list, and db_rotate_password. It stops short of clarifying the scope of deletion, such as whether associated users or data are removed.

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 db_rotate_password or db_create, and no prerequisites, warnings, or exclusions are mentioned. The agent must infer usage from the name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about permissions required, whether results are paginated, or that the response may contain sensitive credentials when includePassword is set. Only the bare direction of the operation (read) is conveyed.

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

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

A single short sentence with no waste, and the scope ('the server's') is front-loaded. It is arguably too terse rather than padded, which is the better failure mode for this dimension.

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 has 6 parameters, 1 required, no output schema, and no annotations, so the description should describe what comes back (names only? host, username, password?) and how to identify the target server. None of that is present, leaving the agent to guess at response shape for a credential-adjacent endpoint.

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

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

Schema description coverage is 83%, with panel, baseUrl, clientKey, applicationKey, and includePassword all documented in the schema itself. The description adds no parameter meaning, but the baseline of 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource ('List the server's databases'), which is enough to separate it from siblings like db_create, db_delete, and db_rotate_password. It does not explicitly name those siblings as alternatives, but the read-only list semantics are unambiguous.

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

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

No guidance on when to call this versus db_create/db_delete/db_rotate_password, and no mention of prerequisites such as which server identifier to use or whether the panel must be selected first. The agent must infer all routing from the tool name alone.

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

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

No annotations are provided, so the description carries the full burden. It says a new password is generated but does not disclose whether the old password is invalidated, whether the caller needs auth privileges, whether the password is returned in the response, or whether the change is persisted—all critical for a mutation tool.

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

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

A single short sentence with no wasted words, front-loading the action. The terseness is appropriate structurally, though it reflects under-specification rather than deliberate economy.

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 six parameters, no annotations, and no output schema, the description is materially incomplete. Most importantly, it does not tell the agent whether the newly generated password is returned by the call, which is essential to invoking this 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 83%, so the schema already documents most parameters (panel, baseUrl, database, clientKey, applicationKey). The description adds no parameter-level meaning beyond the schema; baseline 3 applies when structured data does the heavy lifting.

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

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

States a specific verb ('Generate') and resource ('password for a database'), so the agent knows it produces new credentials for a database. It does not explicitly frame this as rotation/replacement or distinguish it from siblings like db_create/db_delete, which keeps it from 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 instead of db_create or db_delete, no mention of prerequisites (panel/server permissions), and no warning about invalidating existing credentials. The agent must infer usage entirely.

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

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

No annotations are provided, so the description carries the full behavioral burden. It says nothing about whether permissions are replaced or merged, what auth/panel context is required, whether the operation is recursive, or what feedback is returned on failure for a mutation tool.

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

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

One tight, front-loaded sentence with concrete mode examples and zero filler. It is efficient, though the brevity comes at the cost of the coverage noted elsewhere.

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-parameter mutation tool with no annotations and no output schema, a single sentence is insufficient. Key behaviors (batch mode, root-relative paths, connection overrides, error semantics) are left entirely to the schema and inference.

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?

Coverage is 78%, so the schema documents most parameters, but the description adds almost nothing beyond what the schema already says (file, mode, root). It never mentions the batch 'files' array, the panel/server selector, or the inline credential overrides, leaving the multi-file path and connection params without prose context.

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

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

States a specific verb ('Set') and resource ('mode of a file'), with examples 644/755, so an agent knows exactly what it does. It omits the batch ('files') capability that the schema supports, but the core purpose is unambiguous and there are no competing chmod 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?

No indication of when to use this vs alternatives, no mention that it is the tool for both single-file and multi-file permission changes, and no prerequisites. The only hint is 'under a root directory', which is scope, not usage 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?

No annotations are provided, so the description carries the full disclosure burden, yet it omits the destination path/filename, overwrite behavior, archive format, and permission requirements for a write operation. Only the source scope is disclosed.

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

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

A single front-loaded sentence with no filler, but its brevity reflects under-specification rather than tightness of thought.

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

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

A mutation tool with 7 parameters, no annotations, and no output schema; the description should explain where the archive lands and what happens on existing files. It does not, leaving the agent unable to call it confidently.

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 57%; the description only restates 'files' and 'root' while saying nothing about the server, panel, or inline credential override parameters (baseUrl, clientKey, applicationKey). It also leaves ambiguous what 'under a root' means when root is optional.

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 (create) and resource (archive) plus the scoping constraint (files/directories under a root). It implicitly separates itself from files_decompress, but never names the archive format or destination, so it stops short of full differentiation.

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

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

No statement of when to use this over alternatives such as files_decompress or files_upload_url, no prerequisites, and no exclusions. An agent must infer the use case entirely from the tool name and one sentence.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the destination rule ('placed next to the original'), but says nothing about the auto-generated copy name, overwrite/conflict behavior, recursive directory handling, or required permissions for a mutation tool.

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

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

Two short sentences, front-loaded with the action and then the destination constraint. No filler or repetition of the 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 mutating tool with no annotations, no output schema, and 6 parameters, the description is too thin: it leaves copy naming, overwrite semantics, error conditions, and return value entirely unaddressed.

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

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

Schema coverage is 83%, so almost every parameter is already documented in the schema; the description adds no parameter detail. Baseline 3 applies since the schema does the heavy lifting and the description only indirectly confirms 'location' is the source path.

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

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

States a specific verb and resource ('Copy a file or directory'), which is clearer than the bare title. It does not explicitly distinguish itself from siblings like files_rename or files_pull, 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?

No guidance on when to use files_copy rather than files_rename, files_pull, or upload/compress alternatives. The only usage signal is implied by the verb 'copy'.

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

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

With no annotations, the description carries the full disclosure burden, yet it says nothing about overwrite behavior, supported archive formats, extraction target naming, or required permissions. Only the vague "under a root directory" hints at path containment, leaving the destructive potential of a filesystem write unexplained.

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

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

A single front-loaded sentence with zero filler. The brevity costs specification rather than clarity, so it is efficient but under-informative rather than 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?

A 7-parameter, filesystem-mutating tool with no annotations and no output schema; the description should at minimum cover overwrite behavior, source-vs-target path semantics, and format support. One sentence cannot carry that, so the definition is incomplete for the tool's complexity.

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

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

Schema coverage is 57%: 'file', 'server' and 'root' have no schema descriptions. The description loosely maps 'file' to the archive and 'root' to a base directory, but adds no format, path-resolution, or server-vs-panel semantics beyond that. Baseline 3 for moderate coverage 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 verb ("Extract") and resource ("an archive file") plus a scoping note ("under a root directory"). Clear enough to distinguish from files_compress, but it never names the inverse sibling or explains the root scoping.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as files_compress or files_pull. An agent must infer from the name that this is the inverse of compression and that a target root must exist.

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 for a destructive mutation. It never states whether deletion is permanent, whether directories are removed recursively, whether missing paths cause an error, or what permissions/keys are required — all critical for an irreversible operation.

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

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

A single front-loaded sentence with no filler. It is efficient, though the brevity comes at the cost of the behavioral detail noted elsewhere rather than being genuinely complete.

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 seven-parameter destructive tool with no annotations and no output schema, the description omits the information an agent most needs: irreversibility, recursion over directories, auth/override behavior, and error conditions. What exists is accurate but far from 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?

Schema coverage is 71%, so the schema already documents most parameters including the 'names relative to root' semantics. The description's phrase 'under a root directory' loosely frames the root/files pairing but adds no syntax, path-format, or override-precedence 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?

States a specific verb (delete) and resource (files/directories) with scope ('under a root directory') and batch cardinality ('one or more'). It is clearly distinguishable from read-oriented siblings like files_list/files_read, though it never explicitly contrasts with the closer files_rename or files_copy.

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

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

No guidance on when to use this versus alternatives such as files_rename or files_copy, and no mention of preconditions (does the path need to exist, must it be empty for directories). The only usage signal is the word 'delete' in the title.

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 does carry the key behavior: the URL is one-time signed (ephemeral, expires) and binary-safe. It omits TTL, whether the URL requires the panel credentials embedded, and any permission requirements for reading the file.

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 outcome, no filler. The second sentence is slightly telegraphic in phrasing but still useful, so it just misses a 5.

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?

Six parameters, no annotations, no output schema, and the two required identifiers are undescribed everywhere. For a tool whose output is a credential-bearing URL, the description says nothing about expiry, scope of access, or how to use the returned URL, leaving real 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 67% and the two required parameters, 'server' and 'file', have no schema descriptions at all; the description adds no guidance on their format (server ID vs name, absolute path). The optional panel/baseUrl/clientKey/applicationKey overrides are documented in the schema, so baseline 3 applies.

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

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

States a specific verb and resource — 'Return a one-time signed URL to download a file' — plus a distinguishing property (binary-safe). It is clearly separable from files_read/files_write, though it never names a sibling such as files_upload_url or files_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 phrase 'Fetch it outside the model context' implies when this is preferred (binary/large payloads the agent shouldn't inline), but it never states when-not-to-use or points to files_read for text content. Usage is implied rather than prescribed.

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 discloses almost nothing: no mention of recursion, pagination, hidden-file behavior, ordering, or required panel/application key permissions. An agent cannot tell from this text whether the call is a safe read-only listing or what scope of credentials it needs.

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 efficient, though the terseness comes at the cost of content rather than being a model of economy.

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

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

For a 6-parameter tool with multi-tenant override parameters (panel, baseUrl, clientKey, applicationKey), no annotations and no output schema, one sentence leaves the agent without enough context to call it confidently or interpret results.

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?

Coverage is 67%, and the most important parameter for this operation, 'directory', has no description in the schema and no clarification here (is it required? does omitting it list the root?). The description never connects 'path' to a specific parameter, and the panel/server/baseUrl/clientKey override layering that dominates the schema is left unaddressed.

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

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

States a specific verb and resource ('List files and directories') plus a scope ('at a path on the server'), so the agent can distinguish it from files_read or files_write. It does not explicitly contrast itself with any sibling, keeping it below 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 versus files_read, files_download_url, or recursive listing, and no preconditions are stated. Usage is only inferable from the tool name and one-line purpose.

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 must carry the full behavioral burden. It implies a mutation but does not disclose permission requirements, behavior when the folder already exists, path defaults, or the role of the required server parameter.

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

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

The single sentence is efficient and front-loads the action. It is not padded or repetitive, though its brevity contributes to the missing context elsewhere.

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

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

For a 7-parameter mutation tool with no annotations and no output schema, the description is too thin. It omits required parameter semantics, path resolution rules, credential override behavior, and what happens on name conflicts.

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

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

With 7 parameters and only 57% schema description coverage, the description should compensate but does not. It clarifies 'root' only implicitly via 'under a root directory' and says nothing about the required name or server parameters or the inline credential overrides.

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 clear verb and resource: create a new folder. It does not distinguish this operation from sibling files_* tools or clarify that it creates a directory rather than a file, but the core action is unambiguous.

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

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

There is no guidance on when to use this tool versus alternatives such as files_upload_url or files_write, and no prerequisites or exclusions are given. The phrase 'under a root directory' hints at scoping but does not tell the agent when to select 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?

With no annotations, the description carries the full burden but only hints that the file lands on the remote server. It does not disclose overwrite behavior, default background vs. foreground execution, permission/auth requirements implied by clientKey/applicationKey, or any side effects of a 10-parameter 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?

A single front-loaded sentence with no waste. It is efficient but borders on under-specification given the tool's complexity.

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, no-annotation, no-output-schema tool, one sentence is far too thin. It leaves the agent without enough context to pick correct panel/auth options or predict the outcome of the download.

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

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

Schema description coverage is only 60%, so several parameters (url, server, filename, directory) rely on name alone. The description adds no meaning about how directory/filename interact, what 'server' identifies, or how the auth override params behave, failing to compensate for the coverage gap.

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

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

The description states a specific verb and resource ('Download a remote URL') and clarifies the destination is 'onto the server', which distinguishes it from a local download. It does not, however, differentiate itself from siblings like files_download_url or files_upload_url.

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 instead of files_download_url, files_upload_url, or files_write, nor on prerequisites such as panel selection or authentication. The agent must infer usage entirely from the name and 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?

No annotations are provided, so the description carries the full burden. "Raw contents" usefully signals verbatim, unparsed output, but it says nothing about permissions, size limits, encoding, or error behavior for missing files.

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 no padding; the core action is front-loaded and the caveat follows immediately.

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?

There is no output schema, and the description says only "raw contents" without indicating return shape or handling of large/truncated responses. For an unannotated read tool with 6 params, a bit more behavioral detail would help.

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

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

Schema description coverage is 83%, so path format and panel/key overrides are already documented inline. The description adds no meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource (read raw file contents) in the first sentence, which cleanly separates it from list/write/delete siblings in the files_* family. It does not explicitly differentiate from files_download_url, which overlaps in intent.

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?

"Use for text/config files; large or binary files are better downloaded" gives both a when-to-use and a when-not-to-use condition, steering the agent toward the download sibling for binaries. The alternative isn't named by tool name, so routing requires inference.

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

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

With no annotations, the description carries the full behavioral burden for a mutating tool. It states the basic scope but does not disclose overwrite behavior, permission requirements, atomicity, batch semantics, or failure modes.

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 primary action, with no filler. Every sentence contributes directly to the stated purpose.

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

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

For a 9-parameter mutating file tool with no annotations or output schema, the description is thin. It omits mention of batched renames via the 'files' array, panel targeting, and inline credential overrides, leaving the agent reliant entirely on 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 high (89%), so the schema already documents parameters like root, from, to, and files. The description only repeats that paths are relative to root and adds no new meaning beyond the schema.

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

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

States a specific verb+resource ('Rename or move a file/directory') and adds scope ('within the server', 'relative to root'). It does not distinguish itself from siblings such as files_copy or server_rename, but the core operation is 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?

No guidance on when to use this instead of alternatives like files_copy, files_mkdir, or server_rename. The description gives no conditions, 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?

With no annotations, the description carries the full burden. It does disclose a genuinely non-obvious trait — the URL is one-time and the directory is appended because Wings reads the folder from the query string while the panel response ignores it. But it omits the HTTP method/headers to use against the signed URL, the expiry window, and size or path constraints, which are essential to invoke it correctly.

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 purpose; the second sentence is dense but every clause about the directory quirk earns its place. Nothing redundant.

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

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

For a 6-parameter, no-annotation, no-output-schema tool, the definition names the return value (a signed URL) but never describes its shape or the follow-up upload steps. Adequate to identify the tool, insufficient to complete the upload flow without trial and error.

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 83%, so the schema does most of the work. The description nonetheless adds real meaning for `directory` by explaining that it is appended to the signed URL and why, which goes beyond the schema's 'Target folder, e.g. /plugins' text.

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

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

States a specific verb+resource: returns a one-time signed URL for uploading files to the server. This clearly distinguishes it from files_download_url and the other file siblings, though it never explicitly names an alternative.

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

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

No guidance on when to use this versus files_write, files_pull, or files_download_url, and no stated prerequisites (auth, panel selection, whether the target directory must already exist). An agent must infer the whole workflow.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the key mutation behavior that the file is created or overwritten, which is valuable. However, it omits permission requirements, response behavior, size or encoding limits, and whether parent directories are created.

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 efficient sentence with the main action and overwrite behavior front-loaded. There is no wasted text.

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 seven-parameter mutation tool with no annotations and no output schema, the description is too thin. It does not explain required server/panel context, authentication overrides, overwrite implications, or what happens after writing.

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

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

Schema description coverage is only 57%, and several parameters such as server, file, and content have no schema descriptions. The tool description does not clarify the meaning or role of these parameters, nor does it explain panel, baseUrl, clientKey, or applicationKey overrides.

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

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

The description states a specific verb and resource: write raw content to a file. It also adds the important scope detail that the operation creates or overwrites the file. However, it does not explicitly distinguish this tool from nearby file operations such as files_upload_url or files_pull.

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 does not say when to use files_write instead of related tools like files_upload_url or files_pull. There is no guidance on prerequisites, alternatives, or when-not to use this direct-content write path.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It implies a mutation but says nothing about required permissions, what happens when the requested ip/port is already taken, whether the allocation is reversible, or what the tool returns. For a write operation with zero annotation coverage this is a meaningful gap.

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

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

Two short sentences with the core behavior front-loaded and no filler. It is efficient though arguably too terse for a 7-parameter mutation 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?

With 7 parameters, no annotations, and no output schema, the description should explain return shape, error behavior on conflicting ip/port, and how the panel/override parameters interact. None of that is present, so an agent must infer most of the calling contract.

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 57%, and the description adds the one piece of semantics the schema lacks: omitting ip/port triggers auto-assignment of the next free allocation. It adds nothing about the server, panel, or inline override parameters (baseUrl/clientKey/applicationKey), leaving those to their schema descriptions.

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

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

The description uses a clear verb+resource ('Request a new allocation') that identifies the operation as creating an allocation, which implicitly distinguishes it from siblings like network_list, network_delete, and network_set_primary. However, it never ties the action to the required 'server' scope or explicitly names a sibling, so the differentiation is left to inference.

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

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

'With no ip/port the next available one is auto-assigned' gives a genuine usage rule for the optional parameters, which implies when to omit them. But there is no guidance on when to use this versus network_list/network_set_primary, and no prerequisites (panel resolution, permissions) are stated.

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

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

No annotations are supplied, so the description carries the full disclosure burden; it only implies a mutation via 'unassign'. It says nothing about reversibility, required API permission level (admin vs subuser), whether the allocation must be in a particular state, or side effects on server networking.

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 padding is structurally efficient, but at this brevity it reads as under-specification rather than genuine conciseness given a 6-parameter mutation 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?

For a destructive, unannotated, multi-parameter network mutation with no output schema, one sentence is far from complete; key facts about permissions, state requirements and result are absent.

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 67%, and the description adds no parameter meaning beyond the schema. The two required parameters ('server' and 'allocation') are undocumented in both schema and description, so the agent gets no clue what format an allocation identifier takes or how server is identified.

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 ('unassign') and resource ('allocation') scoped to a server, and usefully clarifies that the tool's 'delete' semantics mean unassigning rather than removing a record. It stops short of naming or contrasting the sibling network_assign, so differentiation is implied 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?

There is no guidance on when to use this versus network_assign, network_set_primary, or network_list, and no prerequisites (e.g., whether the allocation must be unassigned from the primary first). The agent must infer usage entirely from 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?

No annotations are provided, so the description carries the full burden. It implies a non-mutating read via 'List', but says nothing about permission requirements, pagination, ordering, or what happens if the server has no allocations. The parenthetical clarifies terminology but adds little behavioral context.

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

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

A single front-loaded sentence that states the core action and clarifies the resource terminology. There is no padding, but also no structure beyond the one 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?

With no annotations, no output schema, and five parameters, the description should do more: it never describes the shape of returned allocations, whether results are read-only scoped, or how panel/baseUrl/clientKey resolution interacts with 'server'. The one-line statement leaves critical calling context unstated.

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

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

Schema description coverage is 80%, so the baseline is 3 even though the description explains no parameters. Notably, the required 'server' parameter has no schema description and the description does not compensate for that gap.

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

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

The description gives a specific verb and resource ('List the server's network allocations') and clarifies what an allocation is ('IP/port assignments'). It is clearly a read operation, distinguishable from mutating siblings like network_assign, network_set_primary, and network_delete, though it never names 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 guidance on when to use this versus siblings such as server_get or network_assign, and no mention of prerequisites (e.g. panel selection or API key requirements) despite five parameters covering those concerns. The list semantics imply read-only usage, but that inference is all an agent gets.

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 says 'Update' but does not disclose permissions required, whether existing notes are replaced, whether changes are persisted, or what the response looks like.

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 wasted words. It is efficient, though its brevity leaves important invocation context unstated.

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 seven parameters, three required fields, panel/auth overrides, no annotations, and no output schema, the description is too sparse. It identifies the mutation target but omits enough operational context that an agent could misinvoke the 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 coverage is only 57%, and the description mentions only notes and allocation indirectly. It does not clarify the roles of server, panel, baseUrl, clientKey, or applicationKey, so it fails to compensate for the undocumented parameters.

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

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

The description states a clear verb and resource: update the notes on an allocation. It is specific enough for an agent to understand the core operation, but it does not distinguish this tool from sibling network tools such as network_assign or network_set_primary.

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, no prerequisites, and no exclusions. The agent must infer that this is the tool for changing allocation notes from the name alone.

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

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

No annotations are provided, so the description carries the full burden. It states the mutation but says nothing about side effects (does the previous primary get demoted?), required permissions, idempotency, or the response. For a write operation with zero structured safety hints, this is a significant gap.

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

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

The single sentence is front-loaded and free of fluff, but at seven words it is arguably undersized for a six-parameter mutation tool with no annotations. It is concise without being complete.

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 no annotations, no output schema, two undocumented required parameters, and an unstated side-effect profile, the description does not provide enough for an agent to invoke this confidently beyond the basic action.

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 67%, and the two required parameters, server and allocation, have no schema descriptions. The tool description adds no meaning to any parameter, so the agent gets no help on what an allocation identifier is or how it relates to a server.

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 and resource: marking an allocation as the server's primary. That distinguishes it reasonably well from network_assign, network_list, and network_set_notes, 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as network_assign. The agent must infer the context entirely from the tool name.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: credentials are persisted locally with chmod 600 and repeated adds are upserts. It omits important mutation semantics — whether omitted keys on update are cleared or preserved, and whether makeDefault changes the active panel.

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

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

Three short sentences, front-loaded with the action and followed by the two facts an agent most needs (local persistence, upsert). No filler.

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

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

For a 7-parameter, unannotated, no-output-schema mutation tool, the description covers purpose and storage semantics but leaves default-panel behavior and update/overwrite rules unexplained, which is where an agent is most likely to cause unintended credential loss.

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 57%; the description adds the semantic that name is the upsert key and that multiple API keys are accepted, which the schema does not state. However it says nothing about makeDefault or how test/apiVersion interact with the add, leaving the most ambiguous parameters to inference.

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 concrete verb and resource ('Register a Pterodactyl panel') and states the identifying inputs (name, base URL, API keys), plus the upsert behavior 'Re-adding the same name updates it.' It does not explicitly contrast with siblings like panel_use or panel_test, so an agent must infer that this is the registration step rather than the selection or validation step.

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 're-adding the same name updates it' line implies a legitimate update scenario, but there is no explicit when-to-use/when-not guidance and no pointer to panel_use (activate) or panel_test (validate keys). Usage is inferable but not stated.

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

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

No annotations exist, so the description carries the full burden. It does disclose one non-obvious return behavior ('API keys are masked'), but it says nothing about read-only semantics, auth requirements, ordering, or whether unregistered/offline panels appear.

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 masking note is worth its space, though it is the only piece of substance beyond restating the name.

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

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

For a simple no-arg list call the definition is serviceable, but with no output schema and no annotations the description could have said more about the returned panel fields or whether inactive panels are included. It is minimally complete rather than thorough.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to document and nothing misleading is claimed.

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

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

The description states a specific verb and resource ('List registered panels'), which is unambiguous against write-oriented siblings like panel_add, panel_use, and panel_remove. It does not explicitly name or distinguish itself from those siblings, which keeps it short of a 5.

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

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

Usage is only implied by 'List'; there is no statement of when to reach for this versus panel_test or panel_use, nor any preconditions. For a zero-parameter enumeration tool the intent is obvious enough that this is adequate rather than harmful.

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, and it says nothing beyond 'delete'. It does not state whether removal is irreversible, what happens to servers or backups associated with that panel, or whether elevated permissions are required — critical omissions for a destructive tool.

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

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

A single six-word sentence that is front-loaded with the verb and free of filler. It is efficient, though its brevity reflects under-specification rather than tight editing.

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

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

For a destructive mutation with zero annotation coverage, no output schema, and undocumented parameters, the description should do substantially more — irreversibility, side effects on related servers, and failure modes are all absent. An agent could not safely predict the consequences of calling this.

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

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

Schema description coverage is 0%, so the schema only reveals that 'name' is a required string. The description's 'by name' adds only the mild clarification that the panel is identified by its registered name rather than an ID, with no format, casing, or naming-convention details.

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 ('Delete a registered panel') plus the lookup key ('by name'), so the agent knows exactly what operation this performs and against what object. It does not explicitly contrast itself with siblings like panel_add or panel_list, but the destructive verb makes the distinction obvious.

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

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

There is no guidance on when to use this versus alternatives, no prerequisites (e.g. whether the panel must first be unused or unreferenced by servers), and no warning about consequences. The agent is left to infer the entire call context from the name alone.

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

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

No annotations exist, so the description carries the whole burden. It usefully discloses that real network requests are made ('lightweight request to each API'), which signals cost and non-destructiveness, but says nothing about what happens on partial failure, whether it reports per-key results, whether it is rate-limited, or what output it returns.

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

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

One front-loaded sentence with no filler and the mechanism stated immediately. Slightly ambiguous wording ('each API' when there is one panel parameter) costs it the top mark.

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

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

For a simple one-optional-param diagnostic tool with no output schema, the description is close but not sufficient: the role of 'name', the behavior when it is omitted, and the shape of the diagnostic result are all unstated, and with no output schema the description is the only place result semantics could be conveyed.

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

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

Schema description coverage is 0% for the single 'name' parameter, and the description never mentions it at all. It is unclear whether 'name' selects one panel, whether omitting this optional parameter tests every configured panel, or what the string refers to — the description does not compensate for the total coverage gap.

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

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

States a specific verb (check/test), a specific resource (API keys for a panel) and the mechanism (lightweight request to each API). This is enough to distinguish it from the sibling set (panel_add, panel_use, panel_list), though the description never names those siblings explicitly and the term 'API keys' differs slightly from the title's 'credentials'.

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 can infer this is a verification step, presumably before or after panel_add/panel_use, but the description never says when to prefer it, that it should follow panel_add, or that panel_list is a different (non-verifying) operation.

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 disclose the key behavioral trait: this mutates session-scoped default state rather than a server resource, and it affects subsequent tool calls. It omits whether the setting persists beyond the session, whether an unknown name errors, and whether validation is delegated to panel_test.

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, the primary effect first and the consequence second. Nothing is wasted and nothing important is 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 a one-parameter session-state tool with no annotations or output schema, the description covers the essential effect but leaves the practical gaps: valid name source, error behavior on unknown panels, and session lifetime. Adequate but not complete enough to call it confidently without trial.

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

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

Schema coverage is 0% — the single 'name' parameter has no type-level documentation beyond being a required string. The description adds nothing about what name refers to (a panel identifier from panel_list?), its format, or whether it must already exist, so the agent learns no more than the parameter label implies.

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 and resource ('Set the active panel') plus the scope ('for this session'), which distinguishes it from sibling state-mutating panel tools like panel_add/panel_remove. It doesn't explicitly contrast itself with panel_list or panel_test, so an agent must infer the boundary rather than being told.

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?

'Tools called without an explicit panel arg use it' implies when the tool matters, but there is no explicit 'call this before X' instruction, no precondition that the panel must exist, and no mention of how to discover valid names (panel_list). Usage is implied rather than stated.

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

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

With no annotations, the description must carry the behavioral burden; "List" does imply a read-only, side-effect-free operation, which is the main thing an agent needs. However, it doesn't disclose that results may be scoped by the panel credentials resolved from the four connection parameters, nor anything about result shape or size.

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

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

A single tight sentence with the resource named first and the usage hint second. Nothing is wasted and nothing important is 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?

Parameters are fully covered by the schema, but with no output schema and no annotations, the description leaves the agent guessing what a permission key looks like (string identifier vs. object) and whether the list varies by panel. For a zero-required-arg lookup tool this is acceptable but thin.

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

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

Schema description coverage is 100%, so all four connection parameters (panel, baseUrl, clientKey, applicationKey) are already documented in the schema. The description adds no additional parameter semantics, which is acceptable at baseline when the schema is this complete.

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 — listing available subuser permission keys — and ties itself to subuser_create, which separates it from the CRUD siblings like subuser_list and subuser_get. It doesn't explicitly say it is the lookup companion for subuser_update or subuser_set_files, but the purpose is unambiguous.

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

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

The parenthetical "use with subuser_create" gives implied usage context, but there is no explicit when-to-call framing, no statement that it takes no required arguments, and no mention of the other subuser mutation tools that also consume permission keys.

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, and it discloses nothing: not whether creation is idempotent, not what permissions or panel-level API keys are required, not that inline baseUrl/clientKey/applicationKey overrides are transient, and not that the schedule is empty until tasks are added. A single sentence for a mutation tool with 13 parameters and zero annotation coverage leaves behavior almost entirely opaque.

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

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

The single sentence is front-loaded and wastes no words, but the brevity comes from omission rather than efficiency. There is no structure to speak of because there is essentially no content beyond the verb and one attribute.

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

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

For a 13-parameter, 7-required mutation tool with no annotations and no output schema, the description should explain scope, required cron fields, credential overrides, and what is returned. It supplies only a cron hint, so an agent would have to infer nearly everything from the schema property names 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 only 38%, so the description must compensate and largely does not. The phrase 'cron expression' does implicitly map minute/hour/day_of_month/month/day_of_week to cron syntax, which is genuine added meaning for five undocumented fields, but required params like server and name, plus is_active and only_when_online, are left with no semantic explanation anywhere.

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

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

States a specific verb (Create) and resource (schedule) plus one defining attribute (cron expression), which is enough to separate it from schedule_list, schedule_get, schedule_update and schedule_delete. It does not say the schedule is server-scoped or that creating it is only the container step before adding tasks, so the purpose is clear but shallow.

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

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

There is no when-to-use or when-not-to-use guidance and no named alternatives. An agent gets no hint about prerequisites (a valid server identifier, panel context, valid cron semantics) or about the follow-up call to schedule_task_create needed to make the schedule useful.

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 for a destructive mutation. It usefully discloses that tasks are deleted along with the schedule, but it does not mention irreversibility, confirmation requirements, permissions, or missing-resource 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?

The definition is a single, front-loaded sentence with no redundant text. It is appropriately sized for its information content, even though more information would be needed for completeness.

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 no annotations, no output schema, and six parameters, the description is too sparse. It leaves required parameters and safety-critical behavior undocumented, so an agent lacks enough context to invoke it responsibly.

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 67%, and critically the two required parameters, server and schedule, are undocumented in the schema. The description only implies that a schedule identifier is needed and adds no meaning for server or the authentication override parameters.

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

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

The description states a specific verb and resource: delete a schedule. Adding 'and its tasks' signals a cascade scope that helps distinguish it from schedule_task_delete, though no sibling is named 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?

There is no guidance on when to use this tool versus alternatives such as schedule_update or schedule_task_delete. The action is inferable from the name, but the description provides no usage context, 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?