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

With no annotations, the description carries the full behavioral burden. It discloses the CLI invocation mechanism, the required agent location, and that stdout/stderr are returned, but it omits execution side effects, permission requirements, timeout behavior, and sandbox implications.

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, front-loaded with the core action and followed by execution details and return behavior. No sentence is wasted.

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

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

The description is adequate for basic invocation: it names the required artifact, execution path, and returned streams. With no annotations and no output schema, it should say more about failure modes, sandbox behavior, and expected side effects.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description clarifies the required agent_name and return streams but adds no semantics for input, verbose, no_sandbox, or project_root beyond what the schema already states.

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

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

States a specific verb and resource: run a local Agent by name. It names the execution mechanism, CLI command, and the required on-disk location, distinguishing it from gene-oriented siblings like run_gene.

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

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

Provides clear context and a prerequisite: the Agent must exist in .rotifer/agents/. However, it does not explicitly name alternatives or state when not to use this tool versus run_gene or test_gene.

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 load and does well: it discloses the auth requirement, that measurement happens server-side by running the Gene rather than being caller-supplied, that certain arguments are rejected, and even the underlying CLI invocation. It stops short of describing what is returned or whether a submission is reversible/overwrites prior results.

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, front-loaded with the action and scope, then prerequisites, then the refusal rule. Slightly dense but every clause carries information; nothing is padded.

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

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

For a two-param tool with no annotations and no output schema, the description covers purpose, prerequisites, alternatives, and the key behavioral constraint. The only real gap is what a successful submission yields (score? URL?), which the agent must infer.

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 gene_name and project_root are already documented (baseline 3). The description adds genuine value by enumerating rejected pseudo-parameters (fitness_value, safety_score, success_rate, latency_score, resource_efficiency), which tells the agent the measurement inputs are off-limits despite not appearing 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?

States a specific verb pair (measure, submit) and resource (local Gene -> Arena), which no sibling tool covers. An agent can distinguish this from run_gene, test_gene, or publish_gene without opening a schema.

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

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

Explicitly states the prerequisites (rotifer login, Gene existing locally) and routes to named siblings: list_local_genes to discover, install_gene to fetch. Also states a negative condition — supplying fitness_value and friends is refused — so the agent knows what not to do.

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 does disclose the shape of what comes back (logged-in flag, username, provider, minutes until token expiry), which is genuinely useful, but it never states that the call is read-only/side-effect free or whether it requires an existing token.

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, purpose first and payload second, with no filler or repetition. Every clause earns its place.

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

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

With no output schema in play, the description adequately documents the return values for a zero-argument status probe. It could add the read-only/auth-free note that annotations would normally supply, but otherwise nothing an agent needs is missing.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. No input semantics need explaining and the description correctly does not fabricate 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 states a specific verb and resource ('Check current authentication status') and the sibling set makes the contrast with login/logout self-evident. It is clear, though it never explicitly names login/logout as the alternatives it is distinct from.

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 call this versus login or logout, or of any prerequisite (e.g. call before an authenticated operation to decide whether to re-authenticate). 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, the description carries the full behavioral burden. It does disclose the computational basis (F(g) fitness) and the output shape (side-by-side fitness breakdown), which is genuine context, but it says nothing about read-only semantics, permission/auth needs, limits, or error behavior when an ID is invalid.

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

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

Two tight sentences with zero filler; the purpose and the return value are front-loaded and nothing is repeated from the schema. Every clause earns its place.

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

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

For a single-parameter, read-oriented comparison tool this is close to sufficient: the description covers what is compared, on what metric, and what comes back. It stops short of noting edge behavior (e.g., invalid/duplicate IDs or whether an aggregate winner is returned), which is a minor gap given the complete schema.

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

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

Schema coverage is 100%, so the schema already documents gene_ids as an array of 2-5 Gene UUIDs. The description's 'two or more Genes' restates the minimum without adding format, ordering, or constraint detail, 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+resource (compare Genes) and names the comparison basis (F(g) fitness metrics), so the operation is unambiguous. It does not, however, distinguish itself from nearby siblings like get_gene_detail, get_gene_stats, or get_arena_rankings, leaving the agent to infer why comparison is preferable.

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: 'Compare two or more Genes' signals the multi-gene case, which weakly differentiates it from single-gene tools such as get_gene_detail. There is no explicit when-to-use, when-not-to-use, or named alternative, so the agent must infer routing.

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

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

With no annotations, the description carries the full disclosure burden. It discloses the CLI invocation and the local-directory prerequisite, but says nothing about side effects (artifacts written to disk), where they land, failure behavior for a missing Gene, or the meaning of 'Returns compilation output'. Partial 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?

Three tight sentences with the purpose front-loaded, the prerequisite second, and the return noted last. Every sentence carries information and there is 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 5-parameter mutation tool with no annotations and no output schema, the description is adequate but thin. It omits artifact side effects, error modes, and any expansion of what the compilation output contains, leaving the agent to infer behavior from the schema alone.

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

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

Schema description coverage is 100%, so all five parameters including the lang enum and check flag are already documented in the schema. The description adds only the required gene_name precondition, which is a marginal gain over structured data. 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 ('Compile') and resource ('a local Gene to WASM') plus the mechanism ('via the Rotifer CLI'), so an agent can distinguish it from run_gene, test_gene, and install_gene. It never explicitly names a sibling it is not, 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?

It gives one clear precondition ('The Gene must exist in the local genes/ directory') but offers no guidance on when to reach for this versus test_gene, run_gene, or wrap_gene, nor when-not to use it. Usage is implied rather than directed.

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

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

With no annotations, the description carries the full burden. It usefully discloses side effects (creates a file under .rotifer/agents/ in the project) and a dependency on local genes. However, it omits overwrite/conflict behavior, permission or auth requirements, and failure modes for a mutation tool with 7 parameters.

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

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

Three short sentences, front-loaded with the core action, followed by persistence location and the precondition. No filler, though the final sentence could be folded into the first for slightly tighter structure.

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 covers the primary mechanics and store location but leaves lifecycle questions unanswered: does creating an existing agent name overwrite or error, and what does a successful call return? 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 100%, so the schema already documents all seven parameters including enums and defaults. The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('Create a new Agent') plus the mechanism ('composing one or more local Genes') and the persistence target. It partially differentiates from siblings by naming wrap_gene as a prerequisite, though it does not explicitly contrast with list_local_agents or agent_run.

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

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

It gives a clear precondition — 'Genes must exist locally' — and an actionable routing hint to use wrap_gene first. There is no explicit when-not guidance or mention of alternatives, but the prerequisite context is strong.

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 does disclose the key trait: 'Read-only: inspects the environment and changes nothing.' That safety profile is exactly what an agent needs before invoking a tool with no annotation hints. It stops short of describing the report's shape, but the core behavior is covered.

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

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

Three tight sentences in a logical order: what it checks, its safety property, and the trigger for using it. No sentence is filler, and the trigger routing is front-loaded in the last sentence where it is most actionable.

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

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

With no output schema and no annotations, the description must stand alone, and it adequately covers purpose, read-only nature, and invocation trigger. A brief hint about the report's content or exit signaling would close the remaining gap, but nothing essential is missing.

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

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

Only one optional parameter, project_root, and schema description coverage is 100%, so the schema already documents it fully. The description does not add format or defaulting details beyond the schema, which is the expected baseline 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 (check the TypeScript→WASM toolchain, esbuild/javy) plus the exact output (what is missing or misconfigured). An agent can distinguish this diagnostic tool from compile_gene and the other gene-management siblings without opening a schema.

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

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

Names an explicit trigger and the sibling context: 'Use this when compile_gene fails — a missing or broken toolchain is the most common cause.' This gives a clear when-to-use rule with the rationale, though it offers no when-not condition or alternative diagnostic path.

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

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

With no annotations provided, the description carries the full behavioral burden. It thoroughly explains the tier system, the meaning of a null rank, and the metrics returned (F(g) before/after fidelity discount, safety, success_rate, latency, resource_efficiency, sample size, unique callers). It does not mention pagination behavior or authentication requirements, but for a read-only ranking tool the disclosure is strong.

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

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

The description is front-loaded with its purpose and then uses a compact parenthetical to define the tiers. Every sentence contributes useful context about tier meanings or returned fields. It is dense without being bloated, though the tier definitions make it longer than a minimal one-liner.

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 or annotations, so the description must explain return values, which it does well by listing the tier semantics and metric fields. It omits pagination details and does not clarify that the domain parameter is optional despite the opening phrase 'for a domain,' which is a minor gap. Overall it is complete enough for an agent to understand and use 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 description coverage is 100%, so the input schema already documents page, domain, and per_page. The description reinforces that results are domain-scoped but adds no syntax or default details beyond what the schema provides. A baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description opens with a specific verb and resource: 'Get Arena rankings for a domain.' This clearly distinguishes the tool from a general leaderboard or gene search by scoping to a domain. It does not explicitly name a sibling tool as an alternative, so it falls just 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?

The description implies usage context by advising to 'Prefer `verified` when picking a Gene for a capability,' which helps an agent interpret the results. However, it does not say when to call this tool versus siblings like get_leaderboard or search_genes, nor does it mention any exclusions. The guidance is useful but indirect.

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 behavioral burden. It does convey that the profile is 'public', implying no authentication is required, but says nothing about what happens for an unknown username, rate limits, or what 'reputation data' actually contains.

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 that states resource and lookup key immediately. It is efficient, though bordering on terse for a tool with no output 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 simple one-parameter read tool this is minimally adequate, and 'profile and reputation data' hints at the return shape. However, with no output schema and no annotations, the description leaves the agent guessing about returned fields, error cases, and auth requirements.

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

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

Schema description coverage is 100% and the single parameter is already documented as 'Creator username', so the schema does the heavy lifting. The description's 'by username' adds no syntax or format detail beyond the schema; baseline 3 is appropriate.

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

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

States a specific verb ('Get') and resource ('creator's public profile and reputation data') with the lookup key ('by username'). The 'by username' phrasing implicitly separates it from the sibling get_my_reputation, but it never names that alternative explicitly.

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

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

Usage is only implied: the 'by username' qualifier suggests use this when you want someone else's profile rather than your own, sitting alongside siblings like get_my_reputation and get_gene_reputation. No explicit when-to-use or when-not-to-use guidance is given.

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

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

No annotations are supplied, so the description carries the full behavioral burden. "Get" implies a non-mutating read, and the either/or input requirement is disclosed, but there is no mention of permissions, error behavior for unknown IDs, or result size. Adequate for a simple getter, but thin given 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?

Two sentences, front-loaded with purpose and followed by the input constraint. Every clause earns its place with 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 two-parameter read tool with full schema coverage, the description covers purpose, returned fields, and the input precondition. The absence of an output schema is largely compensated by naming phenotype, fitness, and metadata, though not-found behavior and precedence between the two identifiers remain 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 100%, so both parameters are already documented, including the conditional-requirement note inside the schema itself. The description restates the either/or rule but adds no format hints, validation behavior, or precedence when both values are supplied. Baseline 3 is appropriate.

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

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

States a specific verb and resource ("Get detailed information about a specific Gene") and enumerates the returned content (phenotype, fitness, metadata). It is clearly a detail-fetch tool rather than a list/search tool, though it never names the sibling tools (search_genes, list_local_genes) that would serve the discovery use case.

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 constraint "at least one of gene_id or content_hash must be provided" gives the caller a concrete precondition. However, there is no guidance on when to use this versus search_genes or list_local_genes, and no note about what happens if the ID does not resolve. Usage is implied rather than fully specified.

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

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

No annotations are provided, so the description carries the full burden. 'Get' implies a read-only lookup and the description usefully discloses the returned score dimensions, but it says nothing about authentication requirements, whether reputation is scoped to a user or community, or any caching/rate behavior.

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

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

A single efficient sentence with the resource and the returned components front-loaded. No wasted words, though it is arguably slightly under-specified rather than truly concise.

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

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

For a simple one-parameter read tool this is close to adequate, and listing the score components partially compensates for the absent output schema. But with no annotations and no output schema, the description should say more about the return shape or any access constraints.

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

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

Only one parameter (gene_id) with 100% schema coverage, so the schema already documents it. The description adds nothing about the format or source of the ID, so the baseline of 3 for high schema coverage applies.

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

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

States a specific verb and resource ('Get detailed reputation breakdown for a Gene') and enumerates the components returned (Arena, Usage, Stability scores). It does not, however, distinguish itself from close siblings like get_gene_stats, get_gene_detail, or get_my_reputation, so an agent must infer which reputation/gene-stats tool applies.

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 exclusions, and no mention of alternatives despite several overlapping siblings (get_gene_stats, get_gene_detail, get_my_reputation, compare_genes). The agent gets no signal about when this tool is preferred over those.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that results are broken down into total, 7-day, 30-day, and 90-day periods, but it does not state read-only behavior, authentication needs, rate limits, or side effects.

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

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

A single sentence front-loads the action and resource, then adds the useful period breakdown. There is no redundant or 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 simple read tool with 100% schema coverage, the description supplies the key return-value context by naming the time-period breakdown. It does not cover output format or safety characteristics, but no output schema exists and the operation is a straightforward get.

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%; the single gene_id parameter is documented as 'Gene UUID'. The description refers to 'a Gene' but adds no additional semantics beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource: it returns download statistics for a Gene, broken down by time period. It is clear, though it does not explicitly distinguish itself from sibling tools such as get_gene_detail or get_gene_reputation.

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, nor any prerequisites or exclusions. The breakdown of periods implies what it returns, but not when an agent should choose 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the returned fields and ranking basis, and 'Get' implies a read-only operation, but it does not mention permissions, rate limits, or whether the result is paginated beyond the limit 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?

Two tightly written sentences with no filler. The core purpose is front-loaded, and the second sentence efficiently enumerates the relevant metrics.

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 list tool with no output schema, the description explains what the leaderboard contains and the fields returned alongside the ranking. It does not explain authentication or error behavior, but those gaps 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?

Schema description coverage is 100%, so the single limit parameter is already documented with its default and maximum. The description adds no additional meaning about the parameter, and the baseline of 3 is appropriate when the schema fully covers parameter semantics.

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

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

States a specific verb ('Get') and resource ('creator reputation leaderboard'), and explains what the leaderboard shows (top creators ranked by reputation score with associated metrics). It is clear but does not explicitly distinguish this tool from siblings like get_arena_rankings or get_my_reputation.

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

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

The description gives no when-to-use guidance, no exclusions, and no mention of alternative tools. It implies the tool is for retrieving a reputation leaderboard, but an agent must infer when this is preferable to get_arena_rankings or get_my_reputation.

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

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

No annotations are provided, so the description carries the burden. It does disclose one important trait ('Requires authentication') and enumerates the returned metrics, which is real behavioral value. However, it omits permissions scope beyond auth, rate limits, and whether the returned window is inclusive.

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

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

Two tight sentences, front-loaded with the purpose and followed by the return summary and auth note. No filler, padding, or restated name/title content.

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, enumerating total calls, success rate, average latency, top tools, and top genes is genuinely useful return-value coverage, and the auth requirement is stated. A simple one-param read tool is adequately described, though permissions/rate-limit context is 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?

Only one optional parameter (days) with 100% schema description coverage, so the schema already documents the default of 7. The description adds no format or boundary detail (e.g., max days) beyond the schema baseline.

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

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

States a specific verb ('Get') and resource ('MCP Server call analytics') with a scope qualifier ('for a given time period'). It is distinguishable from sibling tools like get_gene_stats or get_arena_rankings by naming MCP server analytics explicitly, though it does not call out those siblings.

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

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

Usage is implied by the resource ('call analytics'), but there is no explicit when-to-use guidance, no conditions, and no named alternative among the many get_* siblings. An agent can infer the context but must guess at boundaries.

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 but only discloses the authentication requirement. It does not describe read-only nature, rate limits, error behavior, or what happens if unauthenticated. The auth disclosure is useful but incomplete for a 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?

Two short sentences, front-loaded with the core purpose followed by the authentication prerequisite. Every sentence earns its place and nothing is wasted.

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

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

For a simple read with no parameters, no output schema, and no annotations, the description covers the minimum. However, it does not clarify what 'reputation and stats' returns, and given similar siblings like get_gene_reputation and get_developer_profile, an agent might need more context to choose 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 tool has zero parameters, so parameter semantics are trivially satisfied. Per the rubric, a zero-parameter tool receives a baseline of 4; the description has nothing to compensate for and does not mislead about inputs.

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 (reputation and stats) scoped to the current logged-in creator. This distinguishes it from siblings like get_gene_reputation and get_developer_profile by audience, though it does not explicitly name those alternatives. The purpose is clear but the term 'stats' is somewhat vague.

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 only states a prerequisite ('Requires authentication') and gives no guidance on when to use this tool versus alternatives like get_gene_reputation or get_developer_profile. There is no when-to-use or when-not-to-use information, leaving the agent to infer 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 provided, the description carries the full behavioral burden. It usefully discloses the creation side effect (directory, phenotype.json template, starter files), but it does not mention permissions, overwrite behavior, authentication needs, or failure modes for a filesystem-mutating 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?

The description is three sentences, front-loaded with the core action and followed by concrete details about output and fidelity options. It is efficient and wastes little space, though the final sentence is somewhat parenthetical.

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 project-creation tool with no annotations and no output schema, the description covers the basic action and generated files, but omits important operational context such as authentication requirements, overwrite behavior, and default project location. It is minimally adequate but has clear gaps.

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

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

Schema description coverage is 100%, so each parameter is already documented in the input schema. The description only repeats the fidelity types and creation target, adding no syntax, constraints, or meaning beyond what the schema provides; baseline 3 is appropriate.

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

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

States a specific verb and resource: 'Initialize a new Rotifer Gene project.' It also explains what gets created (directory with phenotype.json template and starter files) and names the supported fidelity types. It does not explicitly differentiate from siblings such as create_agent or install_gene, but the purpose 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?

The wording implies usage for creating a new gene project, but there is no explicit when-to-use guidance, no when-not-to-use condition, and no named alternatives among the many sibling tools. Usage must be inferred 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?

With no annotations, the description carries the burden and does useful work: it discloses that phenotype, metadata, and a compiled WASM artifact are downloaded, and that the artifact is verified against declared size and sha256. It leaves gaps on auth requirements and failure behavior when verification fails.

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 tightly packed sentences: the core action and its source lead, the payload/verification detail follows, and the prerequisite closes. 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?

No output schema or annotations, so the description must stand alone; it covers purpose, source, payload, integrity verification, and input prerequisite. It omits auth/network requirements and the success/failure response shape, which an install-from-remote tool arguably should mention.

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

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

Schema description coverage is 100%, so the schema already documents gene_id, force, and project_root (including the rollback_gene snapshot behavior). The description only adds where a valid gene_id comes from, which the schema does not say.

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 (Install) and resource (a Gene from the Rotifer Cloud Registry) with explicit scope (into the local project), and distinguishes itself from the read-only siblings like search_genes and get_gene_detail that only retrieve metadata.

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 states the prerequisite ('Requires a valid gene_id from search_genes or get_gene_detail'), routing the agent to the right upstream tools. It does not, however, state when NOT to use it or how it relates to compile_gene/run_gene in a 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 supplied, the description carries the full burden and does disclose useful behavior: results are limited to published versions, ordered chronologically, and include changelog entries plus previous_version_id links. It still does not state the read-only nature, pagination, or auth requirements, but the return-shape disclosure is substantive.

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

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

Two tight sentences with zero filler; the scope constraint and the return contents are both front-loaded and immediately actionable.

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

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

For a two-parameter read listing with no output schema, the description supplies enough about return contents (ordering, changelog, version links) to call and interpret it. Minor gaps around pagination and permissions keep it from being fully 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 100% with both parameters fully documented as the creator's username and the gene name, so the schema does the heavy lifting. The phrase 'by creator and name' merely echoes that mapping and adds no new syntax or format detail.

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 (version history chain of a Gene), scoped by creator and name. This clearly separates it from mutating siblings like rollback_gene or publish_gene, though it never names an alternative explicitly.

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

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

Usage is implied by 'version history chain' but the description offers no explicit when-to-use guidance, no conditions, and no pointer to related tools such as get_gene_detail or rollback_gene. An agent must infer the scenario.

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 partially compensates by enumerating the returned fields (name, state, genome composition, strategy, reputation), but omits auth requirements, read-only confirmation, pagination, or error behavior. The 'List' verb implies a read, but this is not stated.

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

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

Three compact sentences, front-loaded with the core action, then return contents, then a clarifying definition. No filler or repetition.

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

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

With no output schema, the description usefully enumerates the returned fields, which is the main gap it needs to fill for a list tool. It remains slightly thin on when to prefer it over sibling listing tools, but nothing critical to invocation is missing.

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

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

Schema description coverage is 100%, so the schema already documents the 'state' filter and 'project_root' default. The description adds no filter syntax, valid values, or interaction detail beyond that, making 3 the appropriate baseline.

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

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

Specific verb + resource: 'List Agents registered in the local project workspace.' It further defines Agents as 'local constructs that compose multiple Genes into pipelines,' which conceptually separates it from list_local_genes. It stops short of explicitly naming the sibling to defer to, so it is clear but not maximally differentiated.

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?

Scoping to the 'local project workspace' implies when this tool applies, but there is no explicit when-to-use statement and no reference to alternatives such as list_local_genes or get_gene_detail. Usage is inferable 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?

No annotations are provided, so the description carries the full burden, and it does disclose real behavior: it scans the genes/ directory for phenotype.json files and reports metadata, compile status, and cloud origin. That is meaningful beyond the schema, though it omits whether the operation is strictly read-only and whether large workspaces incur cost or latency.

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

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

Two tight sentences with zero redundancy: the first states the scope, the second the mechanism and return contents. Information is front-loaded and nothing needs trimming.

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

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

With no output schema and no annotations, the description closes most of the gap by naming the directory scanned and the categories of data returned (metadata, compile status, cloud origin). Only the absence of any safety/permission note and of edge-case behavior (empty workspace, missing genes/) keeps it from being fully complete.

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

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

Schema description coverage is 100%, including the enum for fidelity and an example for the domain prefix, so the schema already documents all three parameters. The description adds no filtering semantics beyond what the schema provides — the baseline 3 for full coverage applies.

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

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

States a specific verb and resource ('List Genes installed in the local project workspace') and adds the mechanism (scanning genes/ for phenotype.json). The 'local' scope distinguishes it from the registry-oriented siblings like search_genes, but the description never names an alternative outright.

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

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

Usage is implied by 'local project workspace' — an agent can infer this is for inspecting what is already installed rather than discovering new Genes. However, there is no explicit when-to-use/when-not statement and no routing to search_genes or list_gene_versions.

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 does meaningful work: it discloses an interactive browser-based OAuth flow and that credentials are persisted locally afterward. It omits edge behaviors such as what happens if already logged in or whether existing credentials are overwritten, keeping it at 4 rather than 5.

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

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

Four short sentences, each earning its place: purpose, mechanism, side effect, and prerequisite. The critical prerequisite is stated last but nothing is padded or redundant.

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

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

With no annotations and no output schema, the description covers the flow, its side effect, and the downstream tools that depend on it. It leaves minor gaps (post-login state, interaction with auth_status/logout), but an agent has enough to invoke it correctly.

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

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

Schema description coverage is 100%, so both parameters (endpoint, provider) are already documented. The description only restates the providers ("GitHub or GitLab") without adding syntax, defaults, or endpoint guidance, so the baseline 3 for high schema coverage applies.

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

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

States a specific verb and resource ("Log in to Rotifer Cloud") and explains the mechanism (OAuth via GitHub/GitLab). It does not explicitly distinguish itself from the related siblings auth_status or logout, so an agent gets a clear purpose but no direct routing help against those near-neighbors.

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

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

Gives an explicit prerequisite: "This must be done before using arena_submit or publish_gene." That tells the agent when this tool is required. It stops short of stating when NOT to call it (e.g., when already authenticated, check auth_status first), so it is clear context without full exclusion 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 behavioral burden. It does disclose one meaningful side effect ('clears locally saved credentials'), which tells the agent this is a state-mutating operation, but it leaves open whether server-side tokens are revoked or only local files removed, and whether other sessions are affected.

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

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

Two short sentences, zero filler, with the action stated first and the side effect second. Nothing is redundant or buried.

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

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

For a no-parameter, no-output-schema session tool, the description covers both the action and its local effect, which is enough to invoke it correctly. It is slightly thin on post-condition detail (whether credentials are revoked remotely, what state the agent is left in), but nothing essential is missing.

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

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

The tool takes zero parameters (schema coverage 100%), so there is nothing for the description to disambiguate. Baseline of 4 applies — no parameter semantics are needed or missing.

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 target ('Log out from Rotifer Cloud') plus the concrete effect ('clears locally saved credentials'), so the agent knows exactly what the tool does. It does not explicitly name its counterpart sibling (login) or contrast with auth_status, so sibling differentiation is only 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?

Usage is implied by the verb itself — an agent will infer it should call this when ending a session or switching accounts — but there is no explicit when/when-not guidance and no mention of the alternative (login) or of auth_status for checking current session state.

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 well: it declares the default destination, that invoking equals explicit publish consent, the V(g) security gate with a Grade >= B threshold, and default-off flags for Arena submission and security checks. It doesn't describe failure/rollback behavior or the response, keeping it short of a 5.

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?

Front-loaded with the action and destination, then prerequisites, then constraints. Every sentence carries information; it is dense but not padded, at roughly three sentences for a tool with many behaviors to disclose.

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 with no annotations and no output schema, the description covers auth, consent, validation, upload, and optional submission. Missing only return-value/error expectations and rollback implications, which are secondary for an agent deciding whether to invoke 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 100%, so the schema already documents all 7 parameters. The description restates the gene_name/all=true mutual requirement and adds the Grade >= B context around security, but adds little syntax or meaning beyond the schema. 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 ('Publish a Gene to Rotifer Cloud Registry') and enumerates the actual steps: validation, upload, optional Arena submission. An agent can distinguish it from nearby siblings like arena_submit, vg_scan, or install_gene.

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

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

Provides prerequisites ('Requires authentication (use login tool first)') and an input precondition ('Either gene_name or all=true must be provided'). It does not explicitly contrast itself with arena_submit, though the optional-submission phrasing implies the relationship.

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 a critical non-obvious trait: 'a rollback consumes its snapshot: it undoes one step, not a history.' That one-way, single-step semantics is exactly the kind of behavior an agent needs. It omits auth/permission requirements and failure behavior, keeping it shy of a 5.

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

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

Three tight sentences, front-loaded with the core action and followed by the invocation mode and the key limitation. No filler; each sentence adds distinct 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 two-optional-parameter mutation tool with no annotations and no output schema, the description covers purpose, listing mode, and the destructive single-step semantics well. It stops short of describing the return/confirmation or error conditions, which leaves a small 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?

Schema description coverage is 100%, so the schema already documents both parameters, establishing a baseline of 3. The description's 'call without gene_name' note largely restates the schema's 'Omit to list what is restorable' rather than adding new syntax or format detail, so it does not lift above baseline.

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

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

The description names a precise verb (undo/restore) and resource (locally installed Gene overwritten by install_gene), and anchors the operation to the sibling install_gene. An agent can distinguish it from install_gene, list_local_genes, and other gene tools without opening any schema.

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

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

It explicitly states how to invoke it in listing mode ('Call without gene_name to list what can currently be rolled back') and scopes the operation to a single step. It does not, however, name an alternative tool for broader history recovery or state when a rollback should be avoided.

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 discloses that execution is local and via rotifer run, but only vaguely states 'Returns execution output' and says nothing about side effects, failure modes, or what the sandbox does. The --allow gating described in the schema is useful but lives in the schema, not the description.

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

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

Three short sentences, front-loaded with the action and CLI, then the prerequisite, then the return. 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?

No output schema, so the description should characterize the return value, and 'Returns execution output' is thin. For a 6-parameter execution tool with sandbox-bypass options and no annotations, more behavioral context is warranted, though the prerequisite and CLI reference cover the essentials.

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 six parameters are already documented in the schema; baseline 3 applies. The description adds no syntax, format, or defaulting detail beyond what the schema provides.

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 (Execute) and resource (a local Gene via rotifer run), plus a locating constraint (must exist in genes/). It is largely distinguishable from siblings like compile_gene or test_gene, though it never explicitly names what separates it from test_gene or agent_run.

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

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

Gives one prerequisite ('must exist in the local genes/ directory') but no when-to-use/when-not guidance and no routing to alternatives such as test_gene or compile_gene. Usage is implied by the verb 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. 'Scan' implies a read-only inspection and it discloses that candidates plus metadata are returned, but it never confirms the absence of side effects, file writes, or the depth/cost of the scan. Adequate but incomplete for an annotation-free 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 tight sentences, front-loaded with the action and scope, then the return. No filler, though the second sentence is fairly generic.

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 four optional params and no output schema, the description gives only a vague 'candidates with metadata' return summary and omits any behavioral detail. It is minimally sufficient to invoke the tool but leaves the output shape and scan characteristics undefined.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's mention of 'source files' vs 'SKILL.md files' loosely mirrors the skills boolean and path params, but adds no format or default detail beyond what the schema already documents.

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

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

States a specific verb (Scan) and resource (source files / SKILL.md files) and the outcome (candidate gene functions wrappable as Genes). It is clearly distinguishable from sibling actions like wrap_gene or list_local_genes, though it never names a sibling explicitly.

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

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

Usage is only implied: the scan-for-candidates framing suggests a discovery step preceding wrap_gene, but the description never states when to choose this over wrap_gene or list_local_genes, nor any prerequisites. No exclusions or alternatives are given.

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

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

No annotations are provided, so the description carries the full burden, and it discloses almost nothing behavioral: no indication whether this searches a remote registry vs. local installs, no pagination cost or rate-limit note, no statement of what an empty result means. 'Returns a list of Genes' is the only behavioral fact offered.

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

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

Two short sentences, front-loaded with the action and resource, with no filler. It is efficient, though truncating the actual return semantics makes the brevity slightly costly.

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, unannotated, output-schema-less search tool, the description is thin: it never explains the paginated return (page/per_page exist but the description implies a flat list) or the relevance-vs-newest default sort behavior that the schema hints at. An agent lacks the context to predict result shape or empty-result behavior.

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

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

Schema description coverage is 100%, so the six parameters (query, domain, fidelity, page, per_page, sort) are fully documented in the schema; baseline 3 applies. The description adds only a restatement of the domain and fidelity filters and no format details, examples, or interaction rules beyond the schema.

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

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

The description gives a specific verb (Search) and resource (Gene ecosystem) and states the return shape — a list of Genes — plus the two filter axes. It does not, however, distinguish this from sibling tools like list_local_genes or scan_genes, so an agent can't tell which search surface to pick from the text alone.

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

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

There is no when-to-use guidance, no mention of when this is preferable to list_local_genes, scan_genes, or get_gene_detail, and no prerequisites. 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?

No annotations are provided, so the description carries the full behavioral burden. It does not disclose that this is a read-only lookup, how many candidates are returned, how 'top matching' is ranked, or what happens when no match is found.

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

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

A single front-loaded sentence with no filler; the verb, resource, and input basis all appear immediately. It is efficient, if a little thin.

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

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

For a simple one-parameter lookup this is minimally adequate. With no output schema, the description could reasonably say what the suggestions look like (names, IDs, scores), and it omits any behavioral notes, leaving gaps an agent must guess at.

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 a single well-documented 'description' parameter, so the baseline is 3. The description restates the parameter's role ('based on a description') without adding format, length, or content guidance 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 ('Suggest') and resource ('top matching domains from the domain registry') plus the matching basis ('based on a description'). It is clearly distinguishable from the gene/agent-oriented siblings, though it does not explicitly name any alternative to route away from.

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, nor on prerequisites or scope limits. The usage context is only implied by 'based on a description'.

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

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

No annotations are provided, so the description carries the full burden. It does disclose that execution happens 'in the sandbox,' which is a meaningful safety signal, but it says nothing about side effects, whether artifacts are written, what happens on failure, or whether compilation output is persisted. The sandbox note is genuine added value but leaves the behavioral picture incomplete.

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 action and scope, followed by the concrete checks performed. Every clause carries information and there is no filler, though the enumeration is slightly dense.

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

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

With no annotations and no output schema, the description should ideally explain what a test result looks like or what distinguishes a pass from a failure. It covers the inputs checked but not the outcome, and it omits the sibling differentiation an agent needs to route correctly among test_gene, compile_gene, and run_gene.

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 parameters (gene_name, verbose, compliance, project_root) are already documented in the schema. The description adds no format, default, or interaction detail beyond what the schema provides, so the baseline of 3 applies.

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

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

The description names a specific verb and resource ('Test a Gene in the sandbox') and enumerates the three internal checks performed (phenotype schema validation, input/output tests, compilation). It is clear what the tool does, but it does not distinguish itself from overlapping siblings such as compile_gene and run_gene, whose functions are a subset of this one.

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 compile_gene, run_gene, or the other validation-oriented siblings. The agent must infer from the tool name alone that this is the comprehensive test entry point.

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 return shape (grade A/B/C/D/? plus per-finding severity, file, line, snippet). It omits whether the scan writes a report file, how long it takes on large repos, or whether any auth/permission is required — meaningful gaps for a scan 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 tight sentences with no filler, front-loading what the tool is before describing the return value. Efficient, though the return sentence could be trimmed since it partially duplicates what an agent infers 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?

There is no output schema, so the description correctly supplies the return shape, and all four parameters are optional and documented in the schema. Still missing are side-effect/permission context and any differentiation from the very similar sibling scan_genes.

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

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

Schema description coverage is 100% and each parameter already has a clear description, so the baseline is 3. The prose adds nothing about the parameters (e.g. what 'all' changes in the report, or how gene_id is used) beyond what the schema provides.

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 (static security scan of Gene/Skill code) and even names the V(g) metric, so the purpose is unambiguous. It does not, however, distinguish itself from the sibling tool scan_genes, leaving the agent to guess which scanner to pick.

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

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

No when-to-use guidance, no prerequisites, and no mention of the sibling scan_genes as an alternative. The only routing hint is the default path behavior implied by 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the output file (phenotype.json) but says nothing about whether wrapping overwrites existing genes, whether writes need auth, or what error surfaces when the target is missing — substantial gaps for a filesystem-mutating tool.

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

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

Three short sentences, front-loaded with the core action and followed by the artifact and the precondition. No filler, though the second and third sentences could be merged without loss.

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

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

With no annotations and no output schema, the description must cover behavior, but it stops at purpose and one precondition. For a 6-parameter write tool in a dense sibling set, the relationship to compile_gene/install_gene and the failure/overwrite behavior are missing.

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

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

Schema description coverage is 100%, so all six parameters (domain, fidelity, gene_name, from_skill, from_clawhub, project_root) are already documented in the schema with examples. The description adds only the precondition on the target, so it sits at the baseline.

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

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

States a specific verb (wrap) and resource (a function or SKILL.md into a Rotifer Gene) plus a concrete artifact produced (phenotype.json). It does not, however, disambiguate itself from siblings like compile_gene, init_gene, or create_agent, which an agent must infer from the 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?

"The target must exist in the project" is a useful precondition, but the description never says when to choose wrap_gene over compile_gene/init_gene or when this step belongs in a workflow. 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.