Fiskmas

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

The annotation readOnlyHint=true already establishes that this is a safe read operation. The description adds the 'poll' behavior and the possible states, but does not disclose additional details like polling intervals or error behavior. Given the annotation coverage, the description adds modest value, hence a 3.

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

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

The description is a single, front-loaded sentence that immediately communicates the purpose and usage. Every word earns its place, and there is no redundancy or 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 simple polling tool with one parameter and no output schema, the description covers the essential context: when to use it, what it returns, and the states. It does not specify error handling or timeout behavior, but these are not critical for an agent to invoke it correctly. Slight gap, hence 4.

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 0% schema description coverage, the description must clarify parameter meaning. It does mention 'for an email', which identifies the sole parameter's role, but does not elaborate on format or constraints. This is minimal but sufficient for a single string parameter, so a 3.

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 action (poll) on a specific resource (onboarding state for an email) and lists the possible return values. This clearly distinguishes it from generic status tools like get_status and aligns with the account lifecycle tools (create_account, delete_account).

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 explicitly states when to use it: 'Use after create_account while waiting for the human to verify.' This provides clear context for the typical workflow, though it does not mention alternatives or when not to use it. Since the context is sufficient for an agent to decide, a 4 is appropriate.

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

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

The annotation only says readOnlyHint=false, so the description carries the burden of explaining side effects. It discloses that a verification email is sent, the account is only pending until the link is clicked, no API token is returned, and the token appears once on the verify page. This is substantial behavioral context beyond the annotation.

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 longer than one line but every sentence earns its place: scope, non-return of token, verification flow, configuration, and routing to whoami. It is front-loaded with 'Start onboarding' and proceeds logically through the sequence. 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 mutating onboarding tool with no output schema, the description covers the full lifecycle from email submission through token configuration and alternative routing. The main missing piece is any explanation of what the API call actually returns beyond not returning a token, and the role of display_name. Overall it gives enough to call 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 0%, so the description must compensate; it only addresses email by saying 'require an email.' The optional display_name parameter is never explained, leaving the agent to guess its role. This is a clear 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 action: start onboarding by creating a pending account with an email and sending a verification link. It clearly distinguishes itself from whoami and account_status by describing the pending/verify flow. The verb and resource 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?

Explicitly instructs 'If you already have a token, call whoami instead,' giving a clear alternative and condition. It also explains the onboarding sequence and the manual verification/token configuration steps, so an agent knows when this tool is the right entry point. This goes beyond generic 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?

Annotations already indicate readOnlyHint=false, so the write nature is known. The description adds valuable behavioral details: it reserves a subdomain, enforces slug regex, checks availability, and explains quota-dependent error behavior. These go beyond the annotation's minimal safety 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?

The description is three sentences long, front-loads the primary purpose, and includes only necessary details. It avoids repetition and every clause adds 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?

The description covers the core action, slug constraints, and quota behavior, but omits any explanation of the name parameter or the return value. Given the tool's simplicity and lack of output schema, these gaps are notable but not fatal; an agent could still call it correctly if it knows name is a project label.

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 description must compensate. It explains the slug parameter's regex and reservation requirement, but offers no explanation for the name parameter. The agent cannot infer what name represents or whether it is required, leaving a significant semantic 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 clearly states the action ('Create a project') and the resource involved, including the reserved subdomain pattern. It distinguishes itself from siblings like create_account or deploy_project by specifying the exact output of reservation and slug constraints.

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

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

The description implies this tool is for creating projects but does not explicitly contrast it with alternatives or state when not to use it. It provides context about quota limits, which hints at when failures occur, but lacks direct guidance on selecting this tool over others.

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

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

Annotations only declare readOnlyHint=false, so the description carries the burden of explaining destructive behavior. It does this thoroughly by disclosing the order of operations (stops/removes projects first), the resource types affected (containers, routes, MariaDB), and the refusal behavior if orphaned runtimes would remain.

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 concise sentences that front-load the core action, then add essential behavioral details. No filler or redundancy.

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

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

For a zero-parameter, destructive account-deletion tool with no output schema, the description fully covers what the agent needs to know: what gets deleted, the order, and the safety guarantee regarding orphaned runtimes.

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

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

The tool has zero parameters, so the schema is fully covered. The baseline for zero-parameter tools is 4, and no additional parameter semantics are needed.

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

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

The description states a specific verb (deletes), the exact resource (the caller's account), and the scope of the action. It also clearly distinguishes itself from delete_project by describing account-level deletion that first removes all projects.

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 clearly communicates the tool's purpose: delete the caller's account. While it doesn't explicitly name alternatives or when-not-to-use, the context is unambiguous enough for an agent to select it for account deletion rather than project-level operations.

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

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

The description reveals that the operation is destructive and includes a quarantine period before the slug is freed, which adds context beyond the readOnlyHint=false annotation. However, it does not disclose whether the deletion is reversible, what data or resources are removed, or what the success/error behavior is.

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, lean sentence with no filler. The destructive action is front-loaded, and the parenthetical adds meaningful nuance without bloating the definition.

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 destructive tool with no output schema, the description covers the main action and one important side effect. It remains somewhat incomplete because the identifier format and quarantine/deletion details are underspecified, leaving room for misinterpretation.

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 description needed to explain what the 'project' parameter should contain. The description only refers to 'a project' and mentions the slug as a side effect, without stating whether the parameter is an ID, name, or slug or providing any format examples.

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 action — stop and delete a project — and adds the distinctive consequence of freeing the slug after quarantine. This is enough to differentiate it from stop_project and get_project, though it does not explicitly name those sibling tools.

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

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

The intended use is implied: use this tool when a project needs to be stopped and permanently deleted into quarantine. There is no explicit 'when not to use' or guidance pointing to stop_project for temporary stops, leaving the choice somewhat inferential.

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

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

Annotations only declare readOnlyHint=false, so the description carries the full disclosure burden. It details the rate limit (1 per 5 minutes, 429 with retry hint), accepted registry, plan memory/CPU caps, and re-deployment rules—far beyond 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 paragraph packs multiple constraints and alternatives without redundancy. The core action is front-loaded, and conditional details (rate limit, plan caps, restrictions) follow logically.

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 covers the action, accepted image source, rate limit, alternative tool, plan caps, and Free plan block. While it does not describe return values (no output schema exists), it notes the rate-limit error scenario, making it complete 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?

With 0% schema description coverage, the description must clarify parameters. It implies that 'image' is a digest from registry.fiskmas.dev and 'project' is the target project, but it stops short of explicit parameter definitions. Still, the context is sufficient for an agent to infer correct usage.

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 action: 'Pull an image by digest and run one container' with explicit plan caps. It also names the accepted registry, distinguishing it from sibling tools like start_project and restart_project.

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

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

Explicitly directs the agent to use restart_project for transient crashes, noting it does not count against the rate limit. It also clarifies when re-deploying is allowed and that starting a second project on Free is blocked.

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

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

The description adds valuable behavioral context beyond the readOnlyHint annotation: it explains that logs are live-pod streams rather than stored history, and that when both tail and since are provided, since takes precedence. This is useful for an agent to predict the tool's behavior. It doesn't contradict the annotation.

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 concise and front-loaded. The first sentence states the core purpose, and the rest adds essential parameter semantics and behavioral notes. Every sentence earns its place, and the precedence rule is clearly stated.

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

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

Given the tool's simplicity (3 optional params, no output schema), the description is quite complete. It explains the key parameters, the log retention model, and the precedence rule. The only minor gap is the project parameter, which is not described, but the overall context is sufficient for an agent to call the tool 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 0%, so the description must compensate. It does: it explains the meaning of tail (line count) and since (time window in seconds), and even provides plan-specific limits (default 200, max 2000, free 24h, plus 7d). The project parameter is not explained, but the description covers the two most important parameters well.

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 clearly states the tool's purpose: returning recent container log lines. It specifies the resource (container logs) and the action (return), and the parameter semantics for tail and since distinguish it from other tools. It is not a tautology and provides concrete detail about what the tool does.

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 explains when to use the tool (to get recent logs) and provides context about the log retention model (live-pod streams, not stored history), which helps an agent understand the tool's limitations. It doesn't explicitly name alternatives or exclusions, but the context is clear enough for an agent to decide when this tool is appropriate.

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

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

The description says 'Fetch', which strongly implies a read-only operation, but the annotation declares readOnlyHint=false, suggesting the tool may have side effects. This is a direct contradiction. No other behavioral traits (e.g., side effects, error on missing project) are 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?

The description is a single, concise sentence with no filler words. It front-loads the core purpose and lookup method, achieving maximum clarity with minimal 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 tool with one simple parameter and no output schema, the description covers the basic purpose, but the contradiction with annotations leaves a critical gap. It does not explain return payload, error behavior, or any side effects, making it incomplete for an agent to use 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?

With schema description coverage at 0%, the description is the only source of parameter meaning. It clarifies that 'project' accepts an id or slug, which adds real value beyond the minimal schema. However, it does not specify format, requiredness, or constraints, so the compensation is partial.

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

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

The description uses a specific verb ('Fetch'), resource ('project'), and scope ('single'), and explicitly names the lookup key ('by id or slug'). This clearly differentiates it from siblings like list_projects or get_status without needing to inspect schemas.

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

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

The description implies usage when a single project is needed by id or slug, but it does not explicitly contrast with alternatives like list_projects or when not to use it. No exclusion or alternative routing is given, leaving context 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?

The readOnlyHint annotation already establishes that this is a safe read operation, and the description adds that the result is raw bytes rather than metadata. It does not disclose behavior for missing skills, whether name is required despite the schema listing zero required parameters, or any size/encoding details, so it adds some but not rich behavioral context.

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

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

The description is a single front-loaded sentence with no filler or redundant information. Every word contributes to the core behavior, making it easy for an agent to parse quickly.

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

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

For a simple read-only tool with one parameter and no output schema, the description covers the main action, parameter role, and return type. However, it omits practical context such as how to obtain valid skill names, whether the name is required, and error behavior when the skill does not exist, leaving some gaps for an agent 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 0%, so the description carries the full burden for explaining the 'name' parameter. It only says the skill is fetched 'by name,' which adds minimal meaning beyond the property name itself. It does not clarify what constitutes a valid name, how to find names, or what happens if no name is provided.

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 ('Return'), a precise resource ('bytes of a platform skill'), and the selection mechanism ('by name'). This clearly distinguishes it from list_skills, which would return a collection, and from other sibling tools focused on accounts, projects, or logs.

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 'by name' implies the tool is used when the caller already knows the skill name, and the need to obtain raw bytes is implied. However, the description does not explicitly mention when not to use it or point to list_skills as the way to discover valid skill names, leaving usage guidance mostly implied.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context: it reports live CPU/mem vs plan caps, deploy history, and plan/per-project caps in the rollup. It doesn't mention pagination or exact response shape, but for a read-only stats tool this is sufficient.

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 sentences, all informative, with the most important scoping behavior front-loaded. No filler or repetition of schema details.

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 read-only stats tool with one optional parameter and no output schema, the description covers the key decision (project vs account-wide), the data reported, and the plan caps. It doesn't describe the exact response structure, but that's not required given the absence of an output schema and the tool's simple scope.

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% and the schema only says `project` is a string. The description compensates by explaining that `project` can be a project id or slug, and that omitting it returns account-wide stats. This adds meaning beyond the schema, though it doesn't specify format constraints (e.g., slug pattern).

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 ('get') and resource ('stats'), and clearly distinguishes between account-wide and per-project stats. It also names the plan caps and deploy history, which makes the tool's purpose concrete and distinct from siblings like get_status or get_logs.

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 explicitly explains when to omit `project` (all of the caller's projects) and when to pass a project id or slug (single project). It also clarifies that the account rollup reports plan and per-project caps, giving the agent clear selection criteria without needing to inspect the schema.

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

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

The description does not contradict the readOnlyHint=true annotation, which carries the safety profile. It adds some behavioral context by enumerating the return fields, but says nothing about error behavior (e.g., unknown project) or response format. Given annotations already establish the read-only nature, this is a baseline-level contribution.

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 that enumerates the tool's outputs efficiently. It is appropriately short for a simple tool, although it could have used the space to document the parameter.

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 low-complexity tool (one simple string param, read-only annotation), the description lists the return themes, compensating for the absent output schema. However, it doesn't specify the nature of the returned fields (e.g., type/format of status) or behavior for nonexistent projects, leaving some gaps.

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

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

Schema description coverage is 0% and the description never explains what the 'project' parameter holds (name, ID, slug, etc.). The parameter is implicitly referenced in 'Return project status,' but at 0% coverage the description should actively clarify the expected value and does not.

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 project status') and lists the concrete return fields (url, image digest, last deploy error). This partly distinguishes it from siblings like get_project and get_logs by naming what it returns, though it does not explicitly name any sibling.

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

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

Offers no guidance on when to use this tool versus alternatives such as get_project, get_stats, or get_logs. The intended use case (status checking) is only implied by the name and description, with no exclusions or conditions 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?

The readOnlyHint annotation already marks this as a safe read operation. The description adds important behavioral context by stating that values are masked and full secrets are never returned, which goes beyond the annotation.

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

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

A single sentence that is front-loaded with the main action and includes the key behavioral guarantee without any wasted words.

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

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

The tool is simple, but the description omits whether the project parameter is optional and what default applies if omitted. Since there is no output schema, a bit more detail about the returned shape or behavior on missing projects would improve completeness.

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

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

With 0% schema description coverage)Skip. The description mentions 'a project' but does not clarify whether the project parameter is required, what happens when omitted, or what format/identifier is expected. The parameter semantics are underspecified.

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

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

The description states a specific verb ('List') and resource ('a project's env keys'), and clarifies that values are masked. This clearly distinguishes it from sibling tools like set_env and list_projects.

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

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

The description implies usage when you need to see environment keys without exposing secrets, but it does not explicitly say when to prefer this over alternatives or exclude any cases, such as when full secret values are needed.

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

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

The readOnlyHint annotation already establishes this is a safe read operation. The description adds that the response includes status and URL fields, but otherwise gives no additional behavioral detail such as pagination, ordering, or whether archived projects are included. It provides some value beyond annotations but not rich 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?

One sentence, no filler, and the core action and scope are front-loaded. Every word carries meaning: verb, subject, scope, and output fields.

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, parameterless read-only list tool, the description is largely complete: it identifies the resource, scope, and returned fields. It doesn't cover edge behaviors like ordering or empty results, but those are minor for this 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?

The tool has zero parameters, so there is nothing for the description to document. The baseline for a zero-parameter tool is 4; the description naturally adds no parameter detail, and none is needed.

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

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

The description states a specific verb ('List'), resource ('the caller's projects'), and output scope ('with status and URL'). It clearly distinguishes from sibling tools like get_project (single project) and list_skills/list_env (different resource types).

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 'the caller's projects' makes the context clear: use when you need the caller's own project list with status and URL. It doesn't explicitly name alternatives or exclusions, but the scope is unambiguous enough for an agent to select it appropriately.

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

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

The readOnlyHint annotation already indicates a safe read operation, and the description adds the caller-scoping detail. It does not describe return format, pagination, or ordering, but the annotations lower the burden here.

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 focused sentence with no wasted words. It is front-loaded with the action and resource and is appropriately sized for a zero-parameter read-only 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 simple, parameterless, read-only listing tool, the description gives enough context for an agent to select and invoke it. It does not explain return values, but 'list' strongly implies a collection of available skills, and no output schema is provided.

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

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

The tool has zero parameters and the schema covers 100% of its parameter information, so the description has no parameter documentation burden. Baseline for zero-parameter tools is 4.

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

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

The description uses a specific verb ('List') and resource ('platform skills') with a clear scope ('available to the caller'). It is clear, but it does not explicitly differentiate itself from sibling tools like get_skill.

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 'available to the caller' implies this is for enumerating the caller's accessible skills, which gives some usage context. However, it provides no explicit guidance on when to use this tool instead of alternatives such as get_skill.

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

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

The annotation readOnlyHint=false already indicates a mutating operation, and the description's 'restart' aligns with that. It adds context that the target is a running project's container, but it does not disclose potential side effects such as downtime, data persistence, or what happens if the project is not running.

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 concise sentence with no filler words. It front-loads the action and target, and every word contributes to the core meaning.

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

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

For a one-parameter tool with no output schema and minimal annotations, the description is incomplete. It does not state behavior for non-running projects, error conditions, or how this relates to start/stop. The agent is left to guess at edge cases and the intended workflow.

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 description must compensate. It implies that the 'project' parameter identifies the project whose container is restarted, but it never explicitly documents the parameter's format, requiredness, or possible values. This leaves the agent to infer the parameter's meaning from the tool name and description.

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 ('restart') and a resource ('a running project's container'), making the tool's function immediately clear. It does not explicitly differentiate from siblings like start_project or stop_project, but the verb itself conveys the distinct restart action.

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 start_project or stop_project, nor any explicit mention of prerequisites like the project needing to be running. The running-project qualifier is the only implicit hint, but no scenarios or exclusions 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?

Beyond the readOnlyHint=false annotation (which already indicates a write operation), the description adds valuable behavior: it explains the effect (reporting for fix), introduces the 'At most one call per session' restriction, and explicitly excludes praise. There is no contradiction with the annotation; the description enriches the agent's understanding of side effects and limits.

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

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

The description is well-structured and front-loaded with the purpose, followed by usage conditions, kind definitions, and a constraint. Every sentence carries meaningful guidance; there is no fluff or repetition. The length is justified by the detailed yet efficient 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 tool with 4 parameters (2 required), no output schema, and no nested objects, the description covers purpose, when/how to use, parameter selection, and constraints. It does not leave gaps that would confuse an agent. The absence of a return-value explanation is acceptable given no output schema, and all essential calling information 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?

With schema coverage at 0%, the description fully compensates by explaining the meaning and selection criteria for 'kind', advising on 'tool' and 'project' usage, and implying the required 'message' content. It adds precise semantics that the schema alone lacks, enabling correct parameter invocation.

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 action (report a problem) and a specific resource (the Fiskmås toolset), with clear intent (so it can be fixed). It differentiates from sibling tools like get_logs or get_status by focusing on feedback and problem reporting, not monitoring or management. The purpose is immediately understandable and not a tautology.

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 explicitly states when to use the tool (tool errored, got stuck, instructions unclear) and when not to (praise). It also provides conditional guidance on choosing the 'kind' parameter (bug, suggestion, other) and clarifies 'tool' and 'project' fields. The constraint 'At most one call per session' is a clear usage rule that prevents misuse.

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

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

The description adds a meaningful behavioral caveat beyond the readOnlyHint=false annotation: the changes are not applied until a restart. It does not mention overwrite semantics, auth requirements, or side effects, but the restart note is valuable and does not contradict any annotation.

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 one concise, front-loaded sentence with no filler. It states the core action and immediately follows with the critical restart caveat.

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 output schema, two parameters, and a nested env object, the definition lacks necessary detail: no return behavior, no env structure, no project identifier guidance, and no mention of required fields. The restart note is the only contextual extra 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 description coverage is 0%, so the description must compensate. It clarifies that 'env' refers to environment variables and 'project' identifies the target, but it does not explain the env object shape, whether project is required, defaults, or how values map. This is insufficient for a nested-object parameter.

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

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

The description uses a specific verb ('Set') and resource ('environment variables on a project'), clearly distinguishing it from read-only tools like list_env and lifecycle tools like restart_project. It unambiguously communicates the core operation.

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 provides useful postcondition context: a restart is required before changes take effect, which hints that restart_project should follow. However, it does not explicitly state when to use set_env versus alternatives such as list_env, nor does it give exclusions or conditions.

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?

readOnlyHint=false already signals mutation; the description adds the precondition that the project must be stopped. However, it does not disclose behavior like whether the call fails if the container is already running, whether it is idempotent, or what state changes occur. Some useful context is present, but significant behavioral details remain undisclosed.

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 entire description is one short, direct sentence with no redundant information. It is efficiently front-loaded with the core action and target.

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

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

The tool is simple, but the missing parameter semantics and lack of usage guidance create real gaps in invoke-correctness. No output schema or additional annotations exist to fill these gaps, so the description is not fully complete. An agent still lacks key invocation details such as how to identify the project and whether the lone parameter is required.

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

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

The schema defines a single 'project' string with no description and no required flag, and the description never explains what value should be passed. Because schema_description_coverage is 0%, the description needed to compensate by defining the parameter format, but it only repeats the word 'project'. An agent cannot tell whether this is a name, ID, or optional with a default.

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

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

The description uses a specific verb ('Start'), names the resource ('project's container'), and qualifies it as 'stopped', making the operation unambiguous. It clearly contrasts with sibling tools like stop_project and restart_project, though it does not name them explicitly. The purpose is immediately understandable to an agent.

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

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

The description offers no guidance on when to choose this tool over siblings such as restart_project or deploy_project, and does not state prerequisites or exclusions. It only implies the tool is for stopped projects. An agent is left to infer usage context from the sibling names.

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

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

Annotations only indicate readOnlyHint=false, so the description carries part of the behavioral disclosure. It adds the important detail that the image is kept, distinguishing stop from delete. However, it does not disclose what happens to the container state, whether the operation is reversible, or whether the container is removed entirely.

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 concise sentence with no filler. It front-loads the action and resource, then adds the key non-destructive detail in parentheses. Every word earns its place.

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

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

For a tool with one parameter and no output schema, the description is terse but missing critical context. The schema marks no parameters as required, and the description does not clarify whether 'project' is mandatory. It also omits behavior when the project is not running, which could cause an agent to call the tool incorrectly.

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 one parameter, 'project', with no description and 0% schema description coverage. The tool description mentions 'a running project's container' but never explicitly explains that the 'project' parameter is the identifier of the project to stop, nor whether it is required. This leaves an agent to infer the parameter's meaning and necessity.

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

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

The description uses a specific verb ('Stop') and a specific resource ('a running project's container'), and the parenthetical '(keep the image)' clearly differentiates it from destructive siblings like delete_project. This is a clear, unambiguous 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?

The description implies when to use the tool: when a project is running and you want to stop it while preserving its image. However, it does not explicitly mention alternatives like start_project, restart_project, or delete_project, nor does it state when not to use it.

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

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

The readOnlyHint annotation already signals safe read behavior; the description adds useful context by enumerating exactly what is returned: provider, plan type, limits, and upgrade_url. It also explains Plus plan details, which helps an agent interpret the response.

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 information-dense sentence that front-loads the core purpose before listing plan details. It is slightly verbose with pricing specifics, but each detail contributes to understanding the return value.

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

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

With no output schema, the description carries the burden of explaining return values, and it does so thoroughly: identity, provider, plan, all limits, and upgrade URL. The tool is simple with no params, and the description fully equips an agent to invoke and interpret 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?

The tool has zero parameters and 100% schema coverage, so the baseline is 4. There is nothing for the description to add about parameter usage, and it does not invent or misrepresent any.

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 clearly states a specific action (return identity of current token holder) and resource (account + provider, subscription plan, plan limits). It is unambiguous and distinct from sibling tools like account_status by focusing on token identity and plan details.

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

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

Usage is implied: call this when you need the current token's identity and plan limits. However, there is no explicit guidance about when to prefer this over siblings like account_status or get_status, and no exclusions are given.

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