Athena MCP Server

by demeet2k

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v3.3.0
Disambiguation2/5
Many tools share the same action suffix (observe, predict, evsi, get, recent, replay) across different model families; for example, there are at least ten *_observe tools and several decision-EVSI variants whose boundaries are only clear from dense descriptions. While domain prefixes help, an agent would frequently need to read lengthy descriptions to avoid mis-selecting between similar causal, GP, Bayesian, and belief variants.
Naming Consistency4/5
The vast majority follow a consistent `athena_<domain>_<action>` snake_case pattern, and the domain prefix provides predictable grouping. However, a minority use bare verb names (hydrate, orchestrate, register, search) or verb-first names (add_edge, apply_transform, reconstruct_state), so the convention is not perfectly uniform.
Tool Count1/5
336 tools is an extreme mismatch for an agent-facing surface. Even with broad domain ambitions, this overwhelms context windows and tool-selection; it should be split into multiple focused servers or drastically consolidated.
Completeness3/5
The surface covers an impressively wide range of domains and many resources have get/recent/replay/state lifecycles. However, several resources lack obvious lifecycle operations (e.g., party leave/disband, branch create/delete, claim revoke/update), and the many model-specific variants do not add distinct capabilities, leaving notable gaps.
Average 3.3/5 across 293 of 336 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 879 commits in the last 12 weeks
- Last stable release on August 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits, but it only states that 'authority is distinct from confidence, truth, consensus, pheromone and reward,' which is a conceptual clarification rather than an operational disclosure. It does not explain side effects, reversibility, what 'reuse' entails, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences), but it under-specifies the tool. The cryptic phrase 'at Y="?"' and the conceptual note about authority take up space without providing actionable information, so the brevity is not a virtue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters and no output schema, the description is critically incomplete. It omits the meaning of register vs reuse, how the claim_id relates to authority, and what the caller should expect in return. There is no mention of side effects or relationships to other claim operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, and the tool description does not explain any of the three parameters (actor, claim_id, source_ref). The agent is left without any semantic meaning for these fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a verb ('Register or reuse') and a resource ('persistent claim authority head'), but the clause 'at Y="?"' is cryptic and does not specify what Y is. It also does not distinguish this tool from the many sibling claim-related tools such as athena_claim_list or athena_discovery_claim_register.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of scenarios, prerequisites, or exclusions, and the description does not reference any sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds some behavioral detail about preserving the BOM separately and differing from generic modules, but omits that this is a read-only operation, any side effects, authentication needs, or error behavior. The jargon further reduces confidence in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but poorly structured. The second sentence is a run-on with unnecessary acronyms and convoluted phrasing, making it hard to parse. The key purpose is front-loaded, but the added detail earns no clarity points because it is more confusing than helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and no annotations, the description is grossly insufficient. It does not explain what machine_id is, what an 'assembly/function packet' contains, or how to interpret the result. The agent cannot reliably invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, machine_id, has no description in the schema (0% coverage). The tool description does not mention machine_id at all, leaving the agent to guess what values are valid or what the parameter signifies. The description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Return an assembly/function packet'), but the resource is vague and the subsequent jargon ('15-part USER_VISUAL BOM', 'primary-source-conditioned infection transition sequence') obscures what the tool actually does. It attempts to distinguish from siblings ('other machines return generic functional modules') but not effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It contrasts with 'other machines' but does not name specific tools or provide decision criteria. The implication that this tool is for T4-specific packets is not directly actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'reinforce' and 'attenuation' without explaining what state changes occur, side effects, persistence, or required permissions. For a likely mutation tool with 9 parameters, this is virtually no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, front-loading the action. It is appropriately short, though some jargon reduces clarity. It earns a high score for structure and economy, but not a 5 because the dense terminology hurts comprehensibility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters, no annotations, no output schema, and no sibling differentiation, the description is severely incomplete. It does not explain what the tool returns, how the attenuation behaves, what 'relatives' are in practice, or how to invoke it correctly. The description is insufficient for an agent to use this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It does not explain any of the parameters (source_scale, coordinates, observations, deposit_gain, etc.) or how they relate to the described behavior. The mention of 'source coordinate' and 'scale-distance' loosely maps to 'coordinates' and 'source_scale' but provides no concrete semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('reinforce') and resource ('source coordinate and declared relatives'), and mentions 'scale-distance attenuation' as a qualifier. However, the terms 'token/artifact/module/domain/system relatives' are jargon-heavy and ambiguous, and it does not explicitly differentiate from sibling tools like athena_pheromone_reinforce or athena_pheromone_multiscale_field beyond using the word 'multiscale'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios, prerequisites, or exclusions. The only hint is the tool's name and the phrase 'scale-distance attenuation,' which implies multiscale scenarios but is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description discloses no behavioral traits—no side effects, state changes, prerequisites, or computational implications. 'DESIGN_ONLY' is ambiguous and does not meaningfully inform the agent about what happens when the tool is invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, but its extreme brevity is under-specification rather than effective conciseness. Given the technical complexity, it should include more context while still being direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a specialized statistical tool with no annotations, no output schema, and a single cryptic sentence. It lacks essential information about inputs, expected outputs, or usage context, making it inadequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions none of the seven parameters. With 0% schema description coverage, the agent is left to guess the meaning of 'context_key', 'actions', 'experiments', 'cost_weight', 'risk_weight', 'seed', and 'samples'. The description provides no value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: estimating expected value of sample information (EVSI) for finite Gaussian linear experiment designs. The phrase 'finite Gaussian linear experiment designs' differentiates it from related decision-analysis tools like athena_decision_evi and athena_decision_evpi, though it does not explicitly name these siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. 'DESIGN_ONLY' is a terse label that hints at scope but does not clarify conditions or alternatives, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It does not state whether the operation is read-only, modifies data, or what output to expect, and only describes algorithmic configuration without addressing side effects or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and free of fluff, with the core method front-loaded. However, it consists of two fragments and is overly terse, sacrificing clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 0% schema coverage, the description fails to provide essential information about inputs, outputs, or usage context. The tool is complex (six parameters, nested objects), and the description does not address any of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It implies treatment and outcome are binary and that assumptions scope the analysis, but it does not explain samples, adjustment, propensity_clip, or the structure of assumptions, leaving most parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a TMLE estimator for binary treatment/outcome, which is specific but lacks an explicit verb like 'estimates' or 'computes'. It differentiates from sibling tools via 'ensemble' but does not clearly state the causal effect estimation purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like athena_causal_tmle_binary. The phrase 'Assumption-scoped' hints at a requirement but does not explain it, and there is no mention of exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It does add some useful context by noting the lazy evaluation and avoidance of materializing the exponential face lattice, but it fails to mention side effects, return behavior, error conditions, or any state changes, which are critical for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence with no filler. It front-loads the core concept ('Represent n-way coordination') and adds a meaningful efficiency detail. However, the dense mathematical terminology might reduce clarity for a general agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter descriptions, the description is far from complete. It does not explain return values, outcome semantics, or how the inputs map to the simplex, leaving substantial gaps for a tool with four parameters and no schema documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining any of the four parameters (participants, task, topic, packet_refs). The parameter names and types alone are insufficient for an agent to know what values to provide or how they relate to the simplex representation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool represents n-way coordination as a lazy (n-1)-simplex, which conveys a specific mathematical approach and distinguishes it from generic 'process' tools. However, it remains abstract and does not clearly specify a concrete operation (e.g., create, compute, transform) or how it relates to the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or scenarios that favor this representation approach, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only says 'hydrate' without disclosing whether this is a read-only load, what side effects occur, or any permissions/rate limits. The term 'hydrate' is ambiguous and no behavioral details are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a list, so it is structurally compact, but heavy use of domain jargon ('JSPACE', 'SCALE', 'canonical organism state') reduces accessibility. It is not as concise as it could be due to unexplained terminology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and described return behavior, this description is severely incomplete. It lists state components but does not explain how the tool behaves, what the output looks like, or how the optional 'agent' parameter affects operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines one optional 'agent' parameter with no description (0% coverage), and the description does not mention it at all. The agent is left without any clue how to populate or use this parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('hydrate') and resource ('current canonical organism state'), and the list of components (head, registry, causal history, etc.) clarifies the scope. However, it does not explicitly differentiate itself from sibling tools like athena_pending_mutations or athena_coordinate_matrix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor any exclusions. It implies usage for loading current state but does not state prerequisites or compare with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only adds that results depend on graph/observed-node/assumption correctness, which is a useful validity caveat, but doesn't mention read-only behavior, side effects, output structure, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and front-loads 'Perform', but it is under-specified for a 10-parameter tool. No structured breakdown of criteria or key parameters is provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 10 parameters, this one-sentence description is far from complete. It omits how to specify the DAG, what method values are valid, and what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 10 parameters with 0% schema description coverage, yet the description names none of them explicitly. Terms like 'supplied-DAG' and 'observed-node' only weakly hint at edges/observed_nodes, leaving method, treatment, outcome, mediators, instruments, assumptions, and max_adjustment_size unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it performs conditional identification on a supplied DAG for backdoor, frontdoor, or instrument criteria, giving a specific verb and resource. It doesn't explicitly distinguish this 'extended' variant from the sibling athena_causal_identify, but the criteria list provides some scope clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this over athena_causal_identify or other causal tools. The caveat about results depending on correctness is a validity note, not usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 the tool selects geometry, right-sizes workers, preserves reserve, and returns a packet, but it does not state whether this mutates state, requires permissions, or has side effects. The read-only nature of a 'plan' is implied but not explicit, leaving behavioral expectations unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence cramming many concepts with slash-separated geometry names and a chain of actions. While not overly long, it is not efficiently structured; the list of geometries (HIVE/SWARM/PACK/FLOCK/HERD/POD) adds noise and could be separated. The intended meaning is obscured by the run-on format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex schema with a required nested signals object and 5 parameters, yet the description provides no explanation of what signals mean, how they influence geometry selection, or what the returned coordinate packet contains. Without an output schema or annotations, the description is critically incomplete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description fails to map any of its language to the actual parameters. It mentions 'reserve capacity' but never names reserve_fraction; it discusses 'right-size workers' without linking to max_workers or unit_cost. The signals object and lineage are entirely absent from the description, so the agent cannot infer parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a multi-step planning action: selecting geometry, right-sizing workers, preserving reserve capacity, allocating roles/topology, and returning a coordinate packet. It differentiates from siblings like athena_collective_allocate or athena_collective_restructure by specifying marginal utility and reserve capacity, but it lacks an explicit verb like 'plan' or 'compute' to fully anchor its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it is a planning step, but it does not state prerequisites, exclusions, or contrast with sibling tools such as athena_collective_restructure or athena_collective_allocate. The 'plan' in the name hints at usage, but the description itself offers no directional cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only says 'Choose' without explaining whether the tool performs the restructuring, returns a recommendation, or has side effects. It does not mention return values, thresholds, or what FISSION/FUSE/HOLD actually do in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and front-loaded, but it is under-specified. It lacks any structured breakdown of inputs, outputs, or decision logic, making it merely a terse summary rather than a helpful guide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a nested metrics object with 9 properties, no output schema, and no annotations, the description is far too minimal. It does not explain how the metrics influence the decision, what the output looks like, or how to interpret the chosen operation, leaving critical gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, yet the description only partially compensates. It mentions several metrics (contagion, cohesion, complementarity, etc.) but omits size_pressure and interface_maturity, and uses 'coordination pressure' which does not match the schema property 'coordination_overhead'. This could confuse an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool chooses among FISSION/FUSE/HOLD operations based on a set of metrics. It is specific to restructuring a collective and distinct from sibling tools like athena_collective_plan or allocate, though it does not explicitly detail what each operation entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as athena_collective_health or athena_collective_plan. It lacks context about prerequisites, whether this is a recommendation or an execution, and when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavior ('rejects stale expected VID' and avoids 'shadow mutation'), but does not explain side effects, return values, permissions, or failure modes. This is minimal transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the verb phrase. The second sentence adds a crucial behavior. No wasted words, though the terseness contributes to overall vagueness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 5 parameters, no annotations, and no output schema, the description is severely incomplete. It does not define 'shadow mutation', explain the expected VID mechanism, or describe what the response looks like. The agent would be left guessing about critical operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no parameter-level meaning beyond the schema field names. The mention of 'expected VID' and 'delta' in the description is oblique and does not clarify their types, formats, or constraints. The agent must infer semantics from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Conditional object mutation' with a distinctive behavior of rejecting stale expected VID. This differentiates it from generic mutation tools, though it does not explicitly name sibling tools for comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for conditional mutations with optimistic concurrency (expected VID check) but provides no explicit when-to-use vs alternatives, no prerequisites, and no exclusions. It fails to guide the agent on when this tool is preferred over siblings like athena_promote_mutation or athena_adopt_mutation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Fit a model' implies a training operation, but it does not disclose whether the model is stored, returned, or if there are side effects, permissions, or state changes. It also does not describe the output format or any failure modes. This is a significant gap for a model-fitting tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that conveys the core purpose without extraneous words. Its structure is straightforward and front-loaded with the action. It could be expanded with parameter details, but as a concise summary it is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 3 parameters, no output schema, no annotations, and a description that only hints at one parameter (scope). The agent has no information about what the function returns, how to supply the 'labelled examples', the meaning of 'l2' or 'iterations', or the practical scope of the model. This is critically inadequate for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate by explaining parameter meanings. The only parameter hinted at is 'scope' via the adjective 'scoped', but 'l2' (likely a regularization strength) and 'iterations' are completely unexplained. Furthermore, the description mentions 'explicit labelled examples' as input, yet there is no parameter for providing data, creating confusion about how the model is actually fitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fit' with a resource 'scoped logistic evidence-dependence model' and specifies the input source ('explicit labelled examples'). This clearly distinguishes it from sibling tools like athena_evidence_dependence_predict or athena_evidence_dependence_observe, which are inference/observation operations. However, the term 'scoped' and 'evidence-dependence' are domain jargon that could be clearer, preventing a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that this is a model-fitting operation that should be followed by prediction tools, nor does it mention any prerequisites or exclusions. The agent is left to infer usage purely from the verb 'Fit' and the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey safety and behavioral traits. It mentions rebuilding from 'frozen module inputs' and comparing outputs, suggesting a non-destructive reconstruction, but it does not state whether this operation has side effects, requires special permissions, or what the return format is. The lack of explicit safety disclosure is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is dense with domain-specific jargon (FIELDRUN, provenance edges, field digest) and may not be immediately scannable. It conveys the core action and comparison items, but structure could be improved for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description carries full burden for context. It explains the action but not the expected return values, error conditions, or when this would be useful. The mention of specific comparisons gives some context, but it is insufficient for an agent to invoke the tool with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, run_id, but schema description coverage is 0%. The description does not explain what run_id refers to or how it relates to 'frozen module inputs'. It fails to compensate for the missing schema documentation, leaving the agent without any semantic understanding of the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific action ('Rebuild') and resource ('FIELDRUN'), and it mentions exactly what is compared. However, it does not explicitly differentiate this from sibling tools like athena_field_get or athena_field_recent, though the verb 'rebuild' provides some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. There are no explicit use cases, prerequisites, or references to sibling tools. The implied context of replay/reconstruction is present but not stated in a way that helps an agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal internal steps (create a third emission MID, coordinate-index visible lexemes, return an ENV envelope) which hint at side effects and processing details. However, it does not clarify whether the operation is destructive, idempotent, or what happens to existing state, and it fails to describe the ENV envelope's contents or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single long, run-on sentence with a colon and a list of six actions. The information is dense and jargon-heavy, making it hard to parse. It lacks clear segmentation (e.g., separate sentences or bullets) and would benefit from front-loading the primary purpose in simple terms before elaborating on internal mechanics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18 parameters, 6 required, nested objects, no output schema), the description is severely incomplete. It does not explain the expected inputs, the meaning or structure of the 'ENV envelope' return value, preconditions, or side effects. The description is only locally intelligible to those already familiar with the Athena system and fails to provide a standalone understanding for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not mention any of the 18 parameters (e.g., text, semantic, native_locator) or map the described 'body'/'header'/'MID' concepts to schema properties. Since the schema lacks descriptions, the description's failure to clarify parameter meaning leaves the agent completely without guidance on how to set required fields like 'semantic' or 'text'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a 'Mandatory emission gateway' and lists a sequence of operations (crystallize body, derive header, assemble, create emission MID, index, return ENV envelope). This conveys a role and some actions, but the heavy use of domain-specific jargon ('crystallize', 'MID', 'ENV') obscures the actual function. It does not clearly distinguish itself from siblings like athena_verify_emission or athena_crystallize_output, making the purpose only vaguely clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states this is a 'Mandatory emission gateway for Athena-aware clients,' implying it must be used when emitting output. However, it provides no explicit when-to-use vs. alternatives, no exclusions, and doesn't name any sibling tools for comparison. The usage context is implied but not thoroughly specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must disclose side effects, return behavior, and operational constraints. It only states the computation and the ambiguous 'DESIGN_ONLY' marker, but does not clarify whether this is a pure read-only computation, what it returns, or what 'DESIGN_ONLY' means functionally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence plus 'DESIGN_ONLY.', so it is concise and front-loaded. However, the jargon-heavy phrasing and unexplained marker make it less readable and not every element contributes clear value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex decision-analysis tool with no output schema, no annotations, and no property descriptions in the schema. The description fails to cover essential context: input structure, meaning of weights, expected output, or usage scenarios. It is far from sufficient for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 7 parameters with zero description coverage. The description mentions 'weighted joint science-twin states' and 'declared outcome likelihoods,' which loosely map to joint_states and possibly some weights, but it does not explain actions, experiments, or the specific weight parameters. The agent cannot infer how to populate the required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes exact finite decision EVI plus entropy reduction over joint science-twin states and outcome likelihoods, which is a specific verb+resource. It distinguishes itself from generic EVI tools by the 'joint science-twin' qualifier, though it does not explicitly refer to sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternative decision-analysis tools (e.g., athena_decision_evi, athena_decision_evpi). The trailing 'DESIGN_ONLY' hints at a usage restriction but is not explained, so the agent is left without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure responsibility. It does disclose two non-behaviors (no standing upgrade, no causal claim) and states that edges are caller-supplied, but it does not describe output, side effects, validation, or error behavior. The term 'standing' is undefined, and the description is too terse to inform the agent of operational consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, which is efficient in length. However, it is cryptic and relies on unexplained acronyms and domain jargon, making it less concise in a helpful sense. It could be equally short while including more concrete terms, so the structure is adequate but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 is the sole source of context. It has 4 parameters, including a nested object array, and operates in a specialized domain. The one-sentence description fails to explain expected return values, edge validation rules, or the relationship to the many sibling tools. This is severely incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds a hint that edges are caller-supplied and 'typed' (likely referring to the 'relation' property) and that standing is not upgraded (relevant to the 'standing' field). However, it does not explain the purpose of src, dst, max_depth, or the edge object fields like directed and source_ref. The parameter semantics are only marginally clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action ('route through') and a resource ('caller-supplied typed edges'), but the abbreviation 'CGR' and the phrase 'without upgrading standing or claiming a causal path' are jargon that obscure the tool's core function. It gives some indication of scope but does not clearly distinguish it from siblings like athena_graph_path or athena_add_edge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The negative constraints ('without upgrading standing or claiming a causal path') imply when not to use it, but no alternative tools or positive use cases are mentioned. The agent is left to infer suitability from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds useful behavioral context ('exact', 'No optimization is invented'), but it does not disclose whether the operation is read-only, what inputs are required, how errors are handled, or what the output contains. This is minimal transparency for a tool with no structured annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main verb and object, and contains no filler. The second sentence adds a meaningful constraint. It is concise, though perhaps too sparse for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex, domain-specific tool with five parameters, no output schema, and no annotations. The description fails to explain parameter semantics, expected relationships between conflicts and dependencies, or the practical context of using kernel analysis. It is far from complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description names none of the five parameters (invalid, patches, conflicts, dependencies, neutral_excluded). The only indirect hint is 'patch kernel' loosely mapping to 'patches', but the meaning and relationships of the other four parameters are entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Analyze') and names a precise resource ('Boolean QHUG patch kernel') and outcome ('exact primal-graph components and structural-free coordinates'), which clearly distinguishes it from optimization-oriented siblings like athena_qhug_pareto_solve. However, it does not explicitly contrast itself with sibling tools such as athena_qhug_decomposition_verify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The phrase 'No optimization is invented' hints that this is not an optimization tool, but the description never states when to prefer this over alternatives or what prerequisites/context are required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only mentions 'create or reuse', hinting at idempotency, but does not explain side effects, error handling, or what happens to existing identities. This is inadequate for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it is extremely terse for a tool with 10 parameters, though conciseness itself is not penalized other than by completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (10 params, nested objects, no output schema, no annotations), a one-sentence abstract description is grossly insufficient. It lacks context on the registration process, return values, and relationship to other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description offers no parameter explanations. It does not clarify the roles of the seven required fields (kind, domain, verb, object_name, method, input_contract, output_contract) or how they form a 'functional signature'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action ('Create or reuse') and a distinct resource ('canonical capability identity' from a 'functional signature'), which differentiates it from sibling tools like athena_register_transform. However, the abstract terminology leaves some ambiguity about the exact nature of the capability identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for registering capability identities, but does not state prerequisites, exclusions, or contrast with similar registration tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It mentions returning a crystal but does not clarify whether the tool mutates state, persists data, requires specific permissions, or has side effects. The phrase 'and RETURN' is ambiguous—does it return a value, or return to caller? This lack of behavioral context is a significant gap for a complex tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is a dense run-on list with slashes and ampersands that is hard to parse. It lacks structure—bullet points or clearer separation would improve readability. It is appropriately short, but the content is packed awkwardly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18 parameters, nested objects, no output schema, no annotations), the description is severely insufficient. It provides no information about return values, error conditions, prereq prerequisites, or examples. An agent would have no way to understand the expected behavior or correctly invoke this tool beyond guessing from the name and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It mentions concepts like math objects, graph/hypergraph deltas, and lexeme coordinates, which map roughly to some parameters (math_objects, edges, coordinates), but it leaves the six required parameters (semantic, text, native_locator, agent, task, seq) entirely unexplained. The description is too high-level to help an agent fill out the schema correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action—compile a visible output into an ATHENA crystal—and lists the major components included, which distinguishes it from generic finalization tools like athena_finalize_output. However, the heavy use of domain-specific jargon (KC144, JSPACE, polyatlas) may obscure the exact purpose for an agent unfamiliar with the ATHENA framework, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as athena_finalize_output or athena_commit_delta. There is no mention of prerequisites, when it should be invoked in a workflow, or any explicit exclusions. The description only explains what it does, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions that the tool returns hydration state and operates against current heads, but does not clarify side effects, mutability, idempotency, or permissions. For a session-start operation, this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, appropriately sized sentence that front-loads the primary action and includes an output hint. No words are wasted, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter descriptions, this one-sentence description is insufficient. It does not cover prerequisites, side effects, expected inputs, or when to use the tool, leaving significant gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the meaning of 'agent' and 'task'. It does not, leaving the agent to infer from parameter names alone. The phrase 'agent session' hints at 'agent', but 'task' remains unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool begins an agent session against the current semantic and Git heads and returns hydration state. This distinguishes it from siblings like athena_session_end and athena_hydrate, though the jargon 'semantic and Git heads' is not explained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention athena_hydrate, athena_session_end, or any other sibling for comparison, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It mentions what is summarized but does not disclose side effects, required permissions, return format, or whether it is a read-only operation. The phrase about automatically metered wall time adds a hint of behavior but is not sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence and is front-loaded with the core verb. It avoids unnecessary words, though the density of jargon slightly harms readability, keeping it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, yet the description is extremely brief. It does not explain the return value, how limit/scope affect results, or what 'persistent resource observations' concretely means, leaving significant gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'limit' or 'scope' parameters at all. The schema provides only basic types and constraints, so the description adds no additional meaning to help an agent use these parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Summarize' and identifies the resource as persistent resource observations plus metered wall time, which distinguishes it from sibling record/schedule tools. However, 'persistent resource observations' is somewhat vague and the phrase 'automatically metered MCP tool-call wall time' is jargon-heavy, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives such as athena_budget_record or athena_budget_schedule. The name implies a summary role, but there are no stated use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only says 'Summarize', which implies a read-only operation, but it does not mention output format, filtering behavior, stability, or any side effects. This is insufficient for an agent to invoke it safely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is easy to parse and front-loads the action. It is not overly verbose, but it lacks additional structural elements like parameter highlights or examples that would enhance clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no output schema, and no annotations, this description is too sparse. It doesn't explain what 'persisted intervention credit' means, what 'causal-confidence history' includes, how parameters affect results, or what the return value looks like. The agent would be left guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with three optional parameters (limit, regime, intervention_id) that lack descriptions. The description does not explain how these parameters relate to the summary; it only vaguely hints at 'intervention credit' which may correspond to intervention_id, but this is not explicit. The description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb ('Summarize') and resource ('persisted intervention credit and causal-confidence history'), which clearly conveys the tool's function. However, it does not distinguish this from sibling summary tools like athena_delayed_credit_summary, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as athena_credit_assign or athena_delayed_credit_summary. The description implies a read/summary operation but offers no exclusions or context about suitable scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a computation ('Rank') but does not disclose side effects, state changes, permissions, or whether it is read-only. 'DESIGN_ONLY' hints at a design-mode restriction but is too vague to convey behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, with a single sentence conveying the core function. However, the appended 'DESIGN_ONLY' is cryptic and not structured as an understandable note, slightly detracting from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no annotations, the description lacks essential context. It does not clarify what 'expected improvement in downstream decision utility' means, what inputs are required, what the output looks like, or how it relates to EVSI/EVPI. The 'DESIGN_ONLY' tag does not sufficiently compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no parameter descriptions, and the tool description does not explain any of the five parameters. Terms like 'candidate experiments' map to 'experiments' but no meaning is added for context_key, actions, cost_weight, or risk_weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool ranks candidate experiments based on expected improvement in decision utility, using a specific verb and resource. However, it does not explicitly differentiate this from sibling tools like athena_decision_evsi and athena_decision_evpi, and 'DESIGN_ONLY' is ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description does not mention any exclusion criteria or preferred use cases beyond the cryptic 'DESIGN_ONLY', which is not explained. No sibling tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers meaningful behavioral details: 'create-if-absent' (conditional mutation), 'separate CLAIM_ACQUIRED event append' (multi-step), 'only from fresh EVENT_READY state' (precondition), and 'preserve lost races and unjournaled effects' (concurrency and side-effect behavior). This goes beyond the schema and gives the agent insight into edge cases, though it remains cryptic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not front-loaded with a plain-language summary. It is a single dense run-on sentence with semicolon-separated internal jargon. While every word tries to pack meaning, the lack of structure and heavy use of undefined terms make it less concise in effect; it prioritizes compactness over clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 13 parameters, no output schema, and no annotations. The description does not explain return values, error semantics, parameter purposes, or the meaning of key concepts like 'EVENT_READY' or 'unjournaled'. It is woefully incomplete for an agent to invoke this tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 8% (just operation_at), and the description mentions none of the 13 parameters. The agent cannot infer what 'expected_source_head', 'expected_frontier_digest', or 'run_id' mean or how to fill them. The description fails to compensate for the sparse schema, leaving parameter semantics completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states an action ('claim create-if-absent' plus 'CLAIM_ACQUIRED event append') and a precondition, but it is shrouded in internal jargon like 'bounded fixed-path', 'fresh EVENT_READY state', and 'unjournaled effects'. It does not clearly communicate the tool's practical purpose to an AI agent, and the differentiation from sibling tools (e.g., prepare/reconcile) is only implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear precondition ('only from fresh EVENT_READY state') and hints at race handling ('preserve lost races'), but it never explicitly states when to use this tool over alternatives like athena_frontier_claim_prepare or athena_frontier_claim_reconcile. The usage context is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool performs a transformation and binding while explicitly avoiding conflation of two states, which is a useful behavioral nuance. However, it does not state whether the operation is read-only, modifies state, requires specific permissions, or has side effects, leaving the safety and impact profile unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the core action ('Reduce exact Git-resident SCHED V3 objective/run state into FRONTIER_PACKET_V1') and includes a meaningful qualifier ('without conflating the two'). There is no redundancy or wasted words, earning a high score for conciseness, though the density of jargon may slightly impair readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 unstructured params, no output schema, no annotations), this description is insufficiently complete. It lacks parameter explanations, expected return values, and any information about prerequisites or side effects. While it captures the core transformation, it leaves critical gaps that prevent an agent from reliably invoking the tool without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for 5 parameters, and the description does not mention any of the parameter names ('task', 'fetch', 'remote', 'profile', 'source_ref') or explain how they map to the described action. The concepts of 'Git-resident' and 'prompt-stack' hint at possible meanings, but there is no concrete mapping, making it impossible for an agent to infer parameter syntax or purpose from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action: reducing exact Git-resident SCHED V3 objective/run state into FRONTIER_PACKET_V1 and binding it to the current prompt-stack digest. This distinguishes it from sibling tools like athena_hydrate or athena_prompt_hydrate by mentioning the specific 'FRONTIER_PACKET_V1' and 'prompt-stack digest' resources. However, heavy jargon without explanation (e.g., 'SCHED V3', 'FRONTIER_PACKET_V1') makes it less immediately transparent, so it does not achieve a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any conditions, enabling scenarios, or exclusions, nor does it name sibling tools for comparison. The only hint is the verb 'Reduce... bind...', which implies a specific use case but offers no explicit decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states two behavioral traits: it does not expose credentials and does not execute a write. This is valuable safety information that goes beyond the name/schema. However, it fails to mention other important behaviors such as whether it performs network calls, what happens if credentials are missing, failure modes, or rate limits. The phrase 'fresh bounded' is also behaviorally vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is dense with unexplained jargon ('fresh bounded', 'five-blob SCHED claim/journal contract') that undermines clarity. It is not effectively front-loaded; the key action 'Report' is present, but the modifiers and contract specifics are opaque. Every word does not earn its place because the audience is unlikely to understand the specialized terminology without additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, no output schema, no annotations) and the large ecosystem of sibling tools, the description is severely incomplete. It mentions what is reported (capability and contract) but does not explain the meaning of 'fresh bounded', 'five-blob', or 'SCHED', nor what the report output looks like. The lack of parameter explanations and usage context makes it difficult for an agent to invoke this tool correctly or interpret its results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 5 parameters with 0% description coverage, and the tool description provides no explanation of what any parameter means. Terms like 'task', 'fetch', 'remote', 'profile', and 'source_ref' are left entirely undefined. The description's mention of 'GitHub' and 'claim-provider' might loosely hint at 'remote' or 'profile', but no direct mapping is given. This is a complete failure to compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Report' and identifies a specific resource: the 'GitHub claim-provider capability' and 'SCHED claim/journal contract'. This distinguishes it from sibling tools that actively claim, prepare, or hydrate, and the added phrase 'without executing a write' makes it clear this is a read-only status tool. However, the heavy jargon ('fresh bounded', 'five-blob SCHED') obscures the exact scope for an unfamiliar agent, and it does not explicitly differentiate itself from siblings like athena_frontier_freshness or athena_frontier_ready.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It only offers a safety note ('without exposing credentials or executing a write'), which implies it is safe for read-only checks, but it does not state the conditions under which this tool should be selected over, say, athena_frontier_freshness or athena_prompt_remote_status. No prerequisites or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of disclosing behavioral traits. It reveals the operation is an update (a mutation), but does not state side effects, required prior state, return values, or error conditions. The phrase 'Bayesian linear update' gives some computational insight but lacks necessary behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, front-loading the core operation. It is efficient and every word earns its place. However, the extreme brevity contributes to ambiguity, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex 7-parameter tool with nested objects, no annotations, and no output schema, yet the description provides only a terse algorithmic statement. It fails to address prerequisites, parameter relationships, or expected outcomes, making it nearly impossible to invoke correctly. The description is drastically under-specified for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It maps 'observed target' to the target parameter and 'feature vector' to features, but the remaining five parameters (context_key, actor, weight, evidence_ref, noise_variance) are left unexplained. The meaning of 'complete feature vector' for the nested object is also ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation: 'Bayesian linear update' from an observed target and feature vector. It references the Gaussian belief resource through the tool name and hints at the data contract via 'complete feature vector', which helps distinguish it from sibling observe tools. However, it doesn't explicitly name the belief object being updated, leaving a slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as athena_bayes_observe or athena_gp_observe. There is no mention of prerequisites (e.g., whether a belief must be registered) or the intended scenario. The use case is only implied by the wording, not explicitly framed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the return value. It does not mention side effects, permissions, state dependencies, or whether this is a safe read-only operation. The phrase 'evidence-weighted' hints at a computational process but is not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loaded with the verb 'Return', and immediately communicates the core output. It is efficiently structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, nested objects, and no output schema, the description is severely incomplete. It omits parameter usage, output structure, and any context about how this tool fits among the many sibling tools, leaving an agent ill-equipped to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters (signals, top_k, domain). It does not describe what 'signals' should contain, how top_k affects results, or what domain values are expected. The description adds no parameter insight beyond the schema's bare names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Return') and a specific resource ('nearest evidence-weighted learned regime centroids plus the coarse V4 regime'), which distinguishes it from siblings like athena_regime_resolve. However, 'coarse V4 regime' is unexplained, and the description does not explicitly differentiate it from athena_regime_geometry_observe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as athena_regime_geometry_observe or athena_resolve. There are no context cues, prerequisites, or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 indicates the tool 'estimates' (suggesting a read-only calculation) but does not disclose return format, side effects, required permissions, or what 'effective evidential replication/falsification diversity' means in practice. The behavioral transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with a clear action verb and front-loaded purpose. It packs many technical terms but does not waste words. There is no fluff or repetition, earning a 4 despite the densely packed jargon.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and 0% schema coverage, this description is severely incomplete. It fails to explain parameter roles, expected outputs, or behavioral constraints. A complex tool like this needs much more context to be invocable correctly by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It names conceptual inputs ('witness confidence', 'independence keys', 'metadata') which partially map to parameters, but it does not explicitly explain claim_id, dimensions, or min_confidence. An agent cannot confidently know how to populate these parameters from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Estimate effective evidential replication/falsification diversity' with specific sources ('witness confidence, independence keys and declared dataset/implementation/method/operator/environment/seed metadata'). This is a specific verb+resource+inputs formulation, but it does not explicitly distinguish from sibling tools like athena_replication_design.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not state prerequisites, use cases, or situations where other tools (e.g., athena_evidence_dependence_probability, athena_replication_design) would be more appropriate. The only implied usage is that it estimates replication diversity, which is not enough for selecting among many similar siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals useful behavioral traits about coordination mode handling (preserving existing intent, AUTO claiming activation, read-only observers). However, since no annotations are provided, it should also disclose side effects, permissions, or return format; the impact of 'refresh' on existing data is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and to the point, with no fluff. It front-loads the core function and adds a relevant nuance in the second sentence. However, given the tool's complexity, it could be better structured to include more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 20 parameters, no annotations, no output schema, and no parameter explanations, the description is severely incomplete. It fails to explain any parameter semantics, expected inputs, or result behavior, leaving an agent unable to correctly construct a call beyond guessing from parameter names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about any of the 20 parameters, and the schema has no per-parameter descriptions. The parameter names like task, fetch, and remote are not self-explanatory in context, and the description fails to compensate for zero schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool refreshes AGENT_BOOT_V1 and its Message Board projection, using a specific verb and resource. It doesn't explicitly distinguish from sibling tools or mention alternatives, so it's clear but not fully differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description explains behavior but doesn't provide context for selecting it over other athena_* tools, or conditions that warrant a refresh. It leaves the agent to infer usage solely from the tool name and the action described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions algorithmic traits (posterior, transfer, uncertainty) but does not disclose side effects, state changes, required inputs, or whether it records outcomes. The absence of any mention of read-only behavior or mutation leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is relatively concise and front-loaded with the core action. However, the dense technical jargon makes it less readable, and the sentence could be split to improve clarity without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with seven parameters, nested objects, and no output schema, yet the description is only one line. It omits return values, side effects, prerequisites, and relationships to sibling tools. The minimal coverage leaves an agent with minimal context to understand what results to expect or what side effects might occur.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, but it does not explain any of the seven parameters. Names like 'arms' and 'context' are self-evident, while 'transfer_tau', 'exploration_alpha', and 'policy_scope' are left entirely undefined. The algorithm phrase 'cross-regime transfer' hints at transfer_tau, but this is indirect and insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Select') with a clear resource ('organization/action experiment') and adds algorithm details (diagonal contextual-UCB, local-regime evidence, cross-regime transfer) that distinguish it from sibling tools like athena_bandit_observe or athena_experiment_design. However, the heavy jargon ('local-regime evidence', 'V3 policy prior') may reduce accessibility for an agent not deeply familiar with the domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention conditions, prerequisites, or exclusions, leaving the agent without clear decision criteria about when selection via this bandit method is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does disclose that posterior/intervals remain model-conditional, which is a useful caveat, but it does not state whether the operation mutates state, requires permissions, or what the return format is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. It is efficient but so sparse that it sacrifices informational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or an output schema, and with cryptic parameter names and nested objects, the description is far too sparse to enable correct invocation. It lacks any explanation of inputs, outputs, side effects, or usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description makes no mention of any of the six parameters. It fails to explain what features, regime, arm_id, ridge, scope, or target_coverage mean, leaving the agent without guidance for constructing valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool performs Bayesian contextual prediction with full covariance and empirical interval calibration, clearly indicating it as a prediction tool. It distinguishes itself via the 'full-covariance' and 'empirical interval calibration' qualifiers, though it does not explicitly compare to siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when full-covariance Bayesian contextual prediction with calibrated intervals is needed, but it provides no explicit when/when-not guidance or alternatives. The technical qualifiers offer some inference, but no direct comparison to sibling tools like athena_transition_predict.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden. It does disclose behavioral details by naming the penalties it exposes (dense-connectivity, duplication, switching, contagion, maintenance), which suggests a read-only analytical role. However, it does not clarify side effects, return format, or whether any state changes occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that packs the core purpose and key concepts without padding. Every phrase contributes, though the heavy jargon may reduce immediate clarity. It is appropriately sized for a complex tool, though not exemplary in readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a nested configuration object with 14 parameters and no output schema, this description is insufficient. It provides an overview of what the tool computes but omits how to configure the evaluation, what the response looks like, and when to use it. The penalty hints are helpful but not enough to fully understand the tool's operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter-specific information, while the schema includes a nested configuration object with 14 properties. With 0% schema description coverage, the agent receives no mapping between the description's 'explicit cost/output vectors' or 'penalties' and the actual configuration fields, such as coupling, switching, or redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Score') and resource ('concrete group organization'), and specifies key outputs (cost/output vectors, return-on-group-organization, and penalties). This clearly indicates the tool's function, though it doesn't explicitly contrast with sibling tools like athena_collective_health or athena_collective_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool over alternatives, nor does it mention prerequisites, exclusions, or context. The implied use case is evaluating a group organization, but this is not made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose safety and side effects, but it only says 'Return'. While the verb implies a read-only operation, it does not explicitly state that there are no side effects, nor does it disclose any performance, rate, or consistency implications. The term 'holonomy observations' could even suggest recording actions, adding ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words, listing all relevant outputs compactly. It is not overly long, but the dense jargon may reduce readability. It is appropriately sized for the complexity, though it could benefit from a bit more structure (e.g., separating the core matrix from auxiliary observations).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (multiple technical outputs, an optional parameter, and no output schema), the description only lists what is returned without explaining the meaning of 'chart-to-chart', 'resolved coordinate subset', or 'holonomy observations'. It does not clarify the purpose of the subject_id parameter or provide any examples. This is insufficient for an agent to confidently use the tool in a domain-specific context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single optional parameter (subject_id) with no description, and schema description coverage is 0%. The description only says 'for an optional subject', providing minimal meaning about what the parameter does. It does not clarify what a 'subject' is, how it filters or modifies the output, or any format requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Return') and a specific resource ('full chart-to-chart transform matrix' plus related data), which distinguishes it from generic tools. However, the heavy jargon ('resolved coordinate subset', 'closed transform triangles', 'holonomy observations') may obscure the primary purpose for an agent without domain context, so it is clear but not maximally accessible.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention any preconditions, exclusions, or relationships to sibling tools such as athena_diffusion_matrix or athena_apply_transform. The only contextual hint is 'for an optional subject', but there is no explanation of when this should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. 'Fetch' implies a read operation, but the description does not explicitly state safety (e.g., no side effects), required permissions, or any rate limits. It also does not clarify whether the operation modifies anything or whether repeated calls are safe. The return behavior is only vaguely noted as 'RETURN state'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words. It lists the fetched items compactly. However, the term 'CYCLE.1' is cryptic and the sentence structure is ambiguous (whether all items are returned or just the state). Despite this, it is appropriately sized and front-loaded with the verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 must clarify return values. It only says 'RETURN state' without specifying the shape of the state or whether the phase artifacts, wait requirements, and receipts are included in the response. The domain-specific terms ('CYCLE.1', 'phase artifacts', 'public phase-event receipts') are unexplained, leaving gaps for an agent without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the cycle_id parameter. The parameter name is self-explanatory to some degree, and the description mentions 'CYCLE.1 state' which loosely ties to cycle identity, but it does not specify where to obtain cycle_id, its format, or its meaning beyond the schema. The description fails to compensate for the lack of schema-level documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and names the resource ('persisted CYCLE.1 state'), and lists additional fetched items (phase artifacts, wait requirements, public phase-event receipts). It is clear this tool retrieves cycle state, but the term 'CYCLE.1' is ambiguous and it does not explicitly distinguish from siblings like athena_cycle_recent or athena_cycle_replay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as athena_cycle_recent, athena_cycle_replay, or athena_cycle_advance. It does not state prerequisites, exclusions, or typical use cases. The only contextual hint is 'persisted', implying a read of stored state, but no explicit alternatives or when-to-use direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a persistence operation and a subtle interpretive note about causation, but it does not mention idempotency, failure behavior, side effects, permissions, or whether the record is appended or overwritten.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. The trailing caveat 'delay alone is not causation' is terse and somewhat cryptic, but it does not detract from the overall brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 8 parameters (5 required), no annotations, and no output schema, the description is too sparse to enable confident invocation. It omits parameter details, return value, and relationship to sibling credit-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only hints at concepts like 'confidence', 'discount', and 'delay' without explaining individual parameters such as actor, regime, outcome_key, or outcome_delta. This is insufficient guidance for correctly populating all 8 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Persist') and the resource ('one confidence-weighted delayed action credit') with an explicit temporal discount. It distinguishes itself as a write operation relative to similar-titled tools like athena_delayed_credit_summary, but does not explicitly name that counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The phrase 'delay alone is not causation' is a conceptual caveat, not usage direction, and no sibling tools are referenced as exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal an important behavioral trait: only witnessed contradiction-free equivalence components are collapse-safe, and UNKNOWN/conflict preserves identities. However, it does not disclose side effects (e.g., whether a snapshot is persisted, whether state is mutated) or return behavior, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at two sentences and front-loads the primary purpose in the first sentence. The second sentence adds a critical safety-related behavioral note, so every sentence earns its place. However, the dense jargon reduces clarity slightly, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, absence of an output schema, and sparse input schema, the description is far from complete. It leaves unresolved key contextual details such as the structure of candidate objects, the role of context_id, side effects of taking a snapshot, and the format or semantics of the result. The cryptic phrasing ('witnessed', 'collapse-safe') further limits an agent's ability to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds essentially no meaning beyond the parameter names. 'candidates' is only mentioned as 'supplied candidates' with no explanation of item structure or requirements, and 'context_id' is not mentioned at all. The description fails to compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action verb ('Construct') and identifies the resource ('contradiction-aware equivalence components') and scope ('over supplied candidates'), giving a clear sense of the tool's core operation despite heavy jargon. It does not explicitly distinguish from sibling tools like athena_equivalence_state or athena_equivalence_observe, but the focus on constructing components from candidates provides reasonable differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus the many sibling equivalence- or state-related tools. The caution about 'collapse-safe' components implies a safety consideration, but there is no direct statement of context, prerequisites, or alternatives, leaving the selection largely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does disclose 'No-write' (a key safety property) and a conditional behavior (PENDING readiness returns a NODE_READY prerequisite instead of manufacturing claim authority). However, it omits many behavioral traits like error conditions, permission requirements, retry semantics, and what the output packet contains beyond being reducer-validated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler and front-loads the core function (no-write preparation). However, the density of unexplained acronyms makes it less effective than a plainer wording; still, it is concise relative to the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (14 params, no output schema, no annotations), this short jargon-laden description is insufficient. It doesn't explain required inputs, return value structure, or how to map the described state terms to schema properties, leaving critical gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 7% (only operation_at has a description), so the description must compensate. It does not explain any parameter meanings or map terms like H/P/F/C/W to specific schema fields. Parameters like expected_source_head, run_id, node_id remain completely unexplained, leaving an agent without necessary guidance to construct a valid request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('No-write preparation') and a specific resource ('CLAIM_V1'), with scope constraints ('bounded fixed-path', 'exact EVENT_READY state'). However, heavy jargon (H/P/F/C/W, NODE_READY, reducer-validated) makes it difficult for an agent outside the domain to grasp. It does not explicitly distinguish from sibling athena_frontier_claim, though 'preparation' implies a pre-step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when in an exact EVENT_READY state with fresh H/P/F/C/W, but gives no explicit when-to-use or when-not-to-use guidance and names no alternative tools. It does not tell the agent to prefer this over athena_frontier_claim or other siblings, making selection guidance weak.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It indicates mutation ('Register/reset') but doesn't disclose side effects like whether it overwrites existing beliefs, the role of the 'replace' parameter, or any prerequisites. It doesn't mention what happens to prior data or any safety considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and includes a useful negative clarification. No wasted words, though it sacrifices depth for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 7-parameter tool with no annotations and no output schema, the description is far too minimal. It doesn't explain return values, parameter semantics, or the difference between register and reset behavior. The tool's schema carries the entire burden, but schema descriptions are absent, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of parameters. It doesn't mention context_key, parameters, mean, noise_variance, prior_variance, replace, or metadata. For a 7-parameter tool, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Register/reset a finite-dimensional Gaussian linear parameter belief in natural form') and explicitly excludes GP/neural/nonparametric posteriors, providing some differentiation from sibling tools like athena_gp_register. However, it doesn't name a specific alternative tool or clarify the exact lifecycle semantics (create vs reset), so it's clear but not fully distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for registering or resetting Gaussian linear beliefs and warns against using for GP/neural/nonparametric posteriors, but it provides no explicit when-to-use or alternatives (e.g., athena_gaussian_belief_observe for observations, athena_gaussian_belief_state for reading). Guidance is minimal and mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose side effects and prerequisites. It only states the ranking computation and 'DESIGN_ONLY', without explaining return format, safety, or whether the hyperposterior must already exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a terse 'DESIGN_ONLY.' marker. It wastes no words but the density and unexplained fragment reduce clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 11 parameters and no output schema or annotations, the one-sentence description is insufficient. It omits prerequisites, output details, and how 'design only' affects behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description names no parameters. It only alludes to decision weights and information weights implicitly via 'EVSI' and 'entropy reduction', leaving most of the 11 parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: ranking candidate GP measurements using a combined EVSI and entropy reduction objective. It distinguishes from sibling tools by the unique 'joint design' criterion, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use guidance or alternatives. The fragment 'DESIGN_ONLY' hints at a design-phase limitation but is not explained, leaving the agent without clear context for selecting this tool over siblings like athena_gp_decision_evsi.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral facts itself. It does state that only bounded non-identity transport is allowed with an explicit source-bearing bridge and declared invariants/loss, which is useful, but it omits side effects, read-only vs mutating behavior, authorization requirements, and return/error behavior. This is insufficient for a complex evaluation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loads the primary action, and contains no filler. However, the second sentence is extremely dense and jargon-heavy, which slightly harms clarity despite the concise structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a highly complex tool with nested schemas, 12 operation enum values, no output schema, and no annotations, yet the description provides almost no guidance on parameter semantics, return values, or failure behavior. It gives only a high-level rule about transport constraints and leaves the agent ill-equipped to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the tool has 6 parameters with nested objects and enums. The description only vaguely alludes to the explicit_bridge parameter through 'source-bearing bridge' and to invariants/loss, but it does not explain required parameters like source, target, operation, risk_class, or target_model_class. It fails to compensate for the missing parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Evaluate') and a specific resource ('one layer-to-layer MCK transport'), giving a clear basic purpose. The second sentence adds scope by describing constraints on cross-layer shortcuts and bridges, which helps distinguish it from sibling transport tools, though the MCK-specific jargon is unexplained and slightly opaque.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus the many sibling transport_* tools. The statements about shortcuts holding and bounded bridge transport are policy constraints rather than actionable usage direction, so an agent is left without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It only states 'List recent persisted AORRUN receipts,' but does not mention whether the operation is read-only, how 'recent' is defined, or any potential side effects. This leaves the agent without safety or behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy or filler. It is appropriately short for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema and has no annotations, so the description should explain return value shape, pagination, and domain terms. It only says 'list recent persisted receipts,' leaving AORRUN undefined and the response format unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single optional 'limit' parameter, but schema description coverage is 0% and the description never mentions it. Since coverage is low, the description must compensate, but it adds no meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recent persisted AORRUN receipts, using a specific verb and resource. However, 'AORRUN' is unexplained jargon, and it does not explicitly differentiate from other 'recent' sibling tools beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like athena_orchestration_get or athena_orchestration_replay. There are no exclusions or explicit use cases, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention whether the operation is read-only, whether it mutates state, what side effects occur, or any preconditions. 'Score' suggests a computation, but no safety or behavioral details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the action and object efficiently, but its brevity contributes to the lack of behavioral and usage detail. It is concise, but perhaps too terse for such a specialized tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested parameter, no output schema, no annotations) and the large sibling list, the description is far from complete. It does not explain the return value, what 'bounded' means, acceptable feature vector formats, or how this scoring relates to other policy tools. A much richer description is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to 'features' by describing it as a 'normalized feature vector', but it does not explain the structure of the nested object or mention the 'scope' parameter at all. The compensation is minimal and incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Score') and the resource ('normalized feature vector'), with a specific qualifier ('current bounded learned organization policy') that gives it a distinct identity among siblings. It does not explicitly differentiate from other policy-related tools, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description implies a usage context ('scoring normalized feature vectors against the policy') but does not state any exclusions, prerequisites, or alternative tools, leaving the agent without explicit decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not indicate whether the operation is read-only, whether results are paginated (despite the 'limit' parameter), or what the response structure looks like. This leaves significant behavioral ambiguity for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It efficiently conveys the core action and resource. However, its brevity is borderline under-specification, so it does not earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema (2 params) but no annotations or output schema, the description should provide more context about return values and parameter semantics. It only states the basic purpose, leaving the agent without enough information to anticipate results or edge cases. The absence of any behavioral or result details makes this insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes 'query' and 'limit' with types and constraints but no descriptions, and the schema coverage is 0%. The description only hints that 'query' is the semantic/canonical text but does not explicitly define it or explain 'limit' (e.g., max results, pagination). The description fails to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search'), the resource ('canonical registry'), and the method ('by semantic/canonical text'). This goes beyond a tautology and gives enough specificity to distinguish it from many siblings, though it does not explicitly contrast with search-like alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as athena_resolve or athena_graph_path. It does not mention exclusions, prerequisites, or preferred scenarios, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool updates 'shrinkage transition statistics' — a mutation — but says nothing about idempotency, persistence, permissions, or what happens on repeated calls with the same transition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is compact and front-loads the action verb with no wasted words. However, the dense jargon ('shrinkage transition statistics') sacrifices clarity for brevity, making it efficient rather than transparently clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, nested objects, no annotations, and no output schema, one sentence is insufficient. Missing semantics include what constitutes an organizational action, how evidence_weight influences statistics, the expected content of before/after, and what the tool returns or how it behaves on repeat calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only implicitly maps 'context transition' to before/after and 'organizational action' to action_id. The parameters actor and evidence_weight are entirely unexplained, and the nested before/after objects have no specified structure, leaving the agent to guess their contents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Record one observed context transition') tied to an organizational action, plus a statistics-update side effect, which goes beyond a mere restatement of the tool name. However, the domain term 'shrinkage transition statistics' is unexplained, and explicit differentiation from the many sibling observe tools is absent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as athena_transition_predict or the other *_observe siblings. It includes no prerequisites, exclusions, or recommended use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects and behavioral traits. It states that the tool updates a posterior and warns 'predictions never train themselves,' but it does not detail persistence, mutability, reversibility, or any necessary permissions. This is insufficient for a mutation-like operation, as the agent cannot infer the full impact of the call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and to the point, with two clauses that communicate the core action and a behavioral warning. It is not verbose, and each phrase contributes some meaning. The cryptic nature of 'predictions never train themselves' slightly reduces clarity, but the overall structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, nested objects, no output schema, no annotations, and no parameter descriptions), the description is far from complete. It does not explain what features or regime represent, how the posterior is represented, or what the result of the update entails. The description provides only a high-level statement, leaving major gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not compensate by explaining any of the six parameters. While 'reward' is implicitly mentioned, the meanings of 'arm_id', 'regime', 'features', and 'global_transfer_weight' are left entirely to guesswork. The tool description provides no added value over the raw property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: updating a single regime/action posterior from an explicit observed reward. The phrase 'one regime/action posterior' scopes the operation, distinguishing it from batch or automatic updates, and the mention of 'explicit observed reward' provides a concrete resource and input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when explicit observed rewards are available to update a posterior. The clause 'predictions never train themselves' hints that this is the manual pathway for incorporating observations, but it does not explicitly name alternatives or provide clear 'when not to use' guidance, leaving the usage context somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses methodological details (cross-fitting, logistic nuisance fits, targeting fluctuation, influence-curve interval) that go beyond the tool name. However, with no annotations, it fails to mention expected output, side effects, or failure modes. 'Assumption-scoped' is vague and does not clarify what happens when assumptions are not met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words, which is concise. However, it is dense with jargon and lacks structure; key information about usage and parameters is omitted, making it efficient but not well-rounded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is methodologically complex (cross-fitted TMLE) and has no output schema, so the description needs to compensate. It fails to explain the input format, output, or when to apply the tool. The minimal one-sentence description is inadequate for an agent to confidently invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries full responsibility for explaining parameters, but it only implies that 'treatment' and 'outcome' are binary. It does not clarify the structure of 'samples', the role of 'adjustment', 'assumptions', or 'propensity_clip'. The term 'binary-treatment/binary-outcome' provides some hint, but it is insufficient for an agent to construct correct arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names TMLE for binary treatment and binary outcome with cross-fitting, which is specific and differentiates it from other causal tools like athena_causal_aipw or athena_causal_tmle_ensemble. However, it does not explicitly state the tool's end goal (e.g., estimate causal effect) and 'Assumption-scoped' is somewhat ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. 'Assumption-scoped' hints at a conditionality but does not specify assumptions or provide decision criteria. The description lacks context about data requirements or when TMLE is preferable to other causal methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose whether the tool is read-only, how delayed credit is aggregated, what 'confidence-weighted' means, or what the response looks like. The verb 'Summarize' hints at a read operation, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the core concept 'delayed confidence-weighted credit by action'. It is appropriately concise for a summary tool, though this brevity comes at the cost of missing contextual details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, no annotations, and the description does not explain key terms, parameter behavior, or return structure. Given the complexity of the domain and the number of sibling tools, this is a minimal-viable description with significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially clarifies action_id via 'by action', but limit and regime are completely unexplained in both the schema and description, leaving the agent unable to infer their meaning or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Summarize' with a specific resource ('delayed confidence-weighted credit') and grouping ('by action'). This distinguishes it from the sibling 'athena_credit_summary' via 'delayed', but it does not explicitly name alternatives, so it is clear but lacks direct sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like athena_credit_summary or athena_delayed_credit_record. The description only implies a summary operation without exclusions, prerequisites, or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose side effects, auth needs, or return behavior. It only lists what is resolved and mentions 'RETURN routes' but does not explain whether this is a read-only operation, what output format to expect, or any potential mutations. This is a significant gap for a complex navigation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense run-on sentence that packs many concepts without clear scannability. It front-loads the verb 'Resolve' but the long list of resolution targets makes it hard to parse. While each item adds scope, a more structured format would improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description should explain return values and usage context. It fails to mention what the tool returns, how results are structured, or any edge cases. Given the complexity of the operation, this is incomplete; an agent cannot predict the tool's behavior effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes 'identifier' as a string, giving no semantics. The description partially compensates by specifying accepted forms (OID/CID/name/CRYS). However, it does not explain any constraints, formats, or examples for these identifier types, leaving ambiguity for an agent invoking the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves an identifier across identity, lineage, manifestations, coordinate charts, JSPACE edges/hyperedges, math objects, crystal versions, and RETURN routes. The verb 'Resolve' and resource 'identifier' are specific, and the enumeration distinguishes this from simpler sibling tools like athena_resolve. However, the heavy jargon may obscure exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives. The description implies a dense/lookup use case but does not state exclusions or compare to siblings like athena_resolve or athena_regime_resolve. There is no 'use when' or 'instead of' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It states that the tool 'computes' metrics, implying a read-only operation, but does not disclose output format, side effects, prerequisites, or any other behavioral traits beyond the computation itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. Every phrase contributes to identifying the tool's function, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a specialized statistical tool with no annotations, no output schema, and no parameter explanations. The description fails to explain what 'effective-N' and 'participation-ratio diversity' mean operationally, what the output looks like, or how dimensions and min_confidence affect results, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters. It implicitly ties claim_id to 'claim's witnesses,' but dimensions and min_confidence are left entirely undefined. The description adds no meaningful semantic information about these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Compute' and names precise resources: 'metadata-similarity effective-N' and 'spectral participation-ratio diversity' for 'science-shadow claim's witnesses.' This clearly differentiates it from sibling tools by identifying unique metrics and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention conditions, exclusions, or related sibling tools, so the agent must infer suitability from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It does reveal that the tool 'persist only' a specific prerequisite and 'require explicit READY', implying it does not automatically mark the node ready. However, it omits critical behavioral traits such as side effects, error conditions, rehydration semantics, or whether current state is mutated. The description is too terse to provide adequate transparency for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the primary action ('Persist... then rehydrate...'). It is concise and avoids extraneous words. However, the extreme density and opaque jargon reduce readability, so it does not earn a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 13 parameters (7 required), no annotations, and no output schema. The description is a cryptic one-liner that does not explain the meaning of the expected_* digests, the rehydration process, the significance of 'require explicit READY', or what the tool returns. It is completely inadequate for an agent to invoke this tool with confidence, making it far from complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 8% (only operation_at has a description). The tool description does not reference any parameter names, but it hints at the digest parameters via 'reducer-validated fixed-sequence' and at node_id via 'PENDING node'. This is insufficient for 13 parameters, especially the required expected_* digests. The description adds minimal meaning beyond the raw schema and does not compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action: persisting a reducer-validated NODE_READY prerequisite for a pending node, then rehydrating and requiring explicit READY. This is a clear verb-resource combination, though heavy domain jargon (e.g., 'fixed-sequence NODE_READY prerequisite') makes it less accessible. It distinguishes itself from sibling frontier tools by focusing on the READY readiness state rather than claiming or hydrating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for one dependency-ready PENDING node' implies a specific usage context: a node that is pending and dependency-ready. This gives some guidance on when to invoke the tool, but there is no explicit mention of alternatives or when not to use it. The description does not reference sibling tools (e.g., athena_frontier_claim, athena_frontier_hydrate) as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 not disclose whether this operation is read-only, has side effects, requires permissions, or what the output format is. The phrase 'frozen inputs' hints at a non-mutating replay, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary verb and resource. No wasted words; all elements support the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, and the description uses domain-specific jargon without explanation. It leaves open critical questions: what a GAPRUN is, what frozen inputs are, what the four comparison outputs mean, and how the output is presented. This is insufficient for a non-expert agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, but it only indirectly references the parameter via 'one GAPRUN'. It does not explain how to obtain a run_id, what valid values look like, or the format expected. The link between run_id and GAPRUN is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'recompile' and identifies the resource 'GAPRUN', and states the comparison of specific outputs (closure nodes, gap, grow, decision digest). However, it doesn't explicitly distinguish this from other replay tools in the family (e.g., athena_field_replay, athena_cycle_replay), and terms like 'GAPRUN' and 'closure nodes' are unexplained, so it's not fully clear to an unfamiliar agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool vs alternatives. It doesn't mention any sibling tools or exclusions. The usage is only implied by the verb 'replay', but no context is given about prerequisites or situations requiring this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'DESIGN_ONLY' as a mode constraint but does not state whether the tool is read-only, has side effects, requires specific permissions, or what the output structure is. The method is mentioned but not the resulting behavior 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two short sentences that each serve a purpose: the first states the core function, the second provides a design-only constraint. No redundant or filler words; it is front-loaded and easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and no annotations, the description is severely inadequate. It does not explain the expected output, the meaning of the parameters, or how to handle edge cases. It is far from complete for an agent to invoke correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the required parameters (context_key, actions, experiments) or optional ones (seed, samples, cost_weight, risk_weight). The phrase 'candidate GP measurements' vaguely relates to experiments but does not add meaningful semantics. The description completely fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Estimate downstream decision value of candidate GP measurements' with a specific method ('conditional-Gaussian Monte Carlo'). It distinguishes from sibling tools like athena_decision_evsi (generic EVSI) and athena_gp_bma_decision_evsi (BMA variant) by explicitly focusing on GP measurements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The 'DESIGN_ONLY' phrase implies a design-phase constraint but does not explain when to choose this over other EVSI/GP decision tools. There are no exclusions, prerequisites, or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals the internal method (deterministic farthest-point subset) but does not mention expected side effects, whether this is a read-only operation, what output or comparison metrics are returned, or how the result is presented. The phrase 'compare the result' hints at behavior but leaves the actual behavior underspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the primary verb 'Approximate'. It contains no filler and wastes no words, making it very concise and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a moderately complex purpose, no annotations, and no output schema. The description is too sparse to fully convey the input expectations, the meaning of the comparison, or the return format. An agent would be left guessing about the details of the 'exact bounded GP reference' and how results are reported.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate by explaining the parameters. It does not mention 'context_key', 'features', 'inducing_count', or 'include_observation_noise' explicitly. The mention of 'deterministic farthest-point subset' loosely relates to 'inducing_count', but the description adds no concrete parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action: approximate the current GP using a deterministic farthest-point subset and compare against an exact bounded GP reference. This distinguishes it from sibling tools like athena_gp_predict or athena_gp_fitc_predict by naming a specific approximation strategy and a comparison target, though it still leaves some ambiguity about what the 'bounded GP reference' is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus sibling tools. The description implies a comparison/validation use case but does not state prerequisites, exclusions, or alternatives. An agent would not know under what conditions to choose this over athena_gp_fitc_predict or athena_gp_predict.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It implies a read operation ('Return') but does not state whether it has side effects, requires permissions, or what 'empirical reliability' entails. The lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It is concise and efficiently communicates the basic purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is inadequate for a tool that appears to retrieve complex, versioned policy state. It leaves key terms unexplained and does not address potential edge cases or return behavior, making it incomplete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines one optional parameter, 'scope', with no description. The description mentions 'for a scope' but does not clarify what a scope is, what values it accepts, or how it affects the result. With 0% schema coverage, the description fails to compensate for the missing parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Return') and identifies a specific resource ('versioned bounded organization-policy state' and 'empirical reliability') for a scope. It is distinct from sibling tools like athena_policy_score or athena_policy_update, though the jargon-heavy terms reduce clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or comparisons to sibling tools, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It says the tool 'requires rehydration on material shared changes', but does not clarify whether this is a read-only check or a mutating operation, what 'rehydration' entails, or what side effects occur. The tool's behavior is under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the core action. No wasted words, and it fits in one line while conveying purpose and a hint of behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema, no annotations) and a large sibling set, the description is far too thin. It lacks parameter semantics, return behavior, side effects, and usage context, leaving the agent to guess at critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), so the description must explain the parameters. It does not mention any parameter names or meanings, though 'expected_git_head' and 'expected_prompt_stack_digest' are lightly implied by the reference to 'prompt/Git ancestry'. This is insufficient for an agent to correctly fill the fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: compare an agent's prompt/Git ancestry with the current brain and require rehydration on material shared changes. This goes beyond a vague restatement and gives a distinct purpose. However, it does not explicitly distinguish itself from sibling tools like athena_rehydration_verify or athena_prompt_hydrate, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It implies a freshness-check/rehydration-trigger role, but does not state prerequisites, exclusions, or mention any sibling tool as a fallback. Without this, the agent must infer usage from the vague wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It mentions the promotion is gated and targets the 'canonical Git prompt module', suggesting a mutating operation. However, it does not state permissions, reversibility, failure behavior, or what 'CAS-promote' entails. The description is not misleading, but it leaves significant behavioral aspects unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action ('CAS-promote') and is free of fluff. It is appropriately concise for its purpose, though the unexplained 'CAS' jargon slightly reduces clarity. Overall, it is well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, a nested object, no annotations, and no output schema, but the description is very short. It does not explain how to specify gates, what the refs mean, or what the function returns. High-level purpose is clear, but operational completeness is lacking for an agent to invoke it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only hints that 'regression, adversarial, replay' relate to experiment_refs and 'evidence' to evidence_refs, but does not explicitly map them. It provides no meaning for candidate_ref, expected_git_head, actor, or witness, leaving these parameters ambiguous. The description adds almost no value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'CAS-promote a tested candidate into its canonical Git prompt module'. This specifies a concrete verb and resource, distinguishing it from generic tools. However, it doesn't explicitly differentiate from sibling tools like athena_prompt_publish or athena_prompt_propose, so it lacks direct sibling comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'only with regression, adversarial, replay and evidence gates' implies a clear precondition for use—the gates must be satisfied before promotion. This gives some usage guidance but does not mention when to use this tool versus alternatives or provide explicit when-not-to-use scenarios. It is implied that this is for post-testing promotion, but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It adds 'deterministic' as a useful trait but does not state whether the operation is read-only, how invalid or non-normalized inputs are handled, or whether there are any side effects. This is minimal disclosure for a resolve-style tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence with no redundant wording; every phrase contributes to the core purpose. This is appropriately concise for a tool with a focused responsibility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nested parameters, no annotations, and no output schema, yet the description does not explain the returned key format, allowed values, or the role of the 'domain' parameter. This leaves significant gaps for an agent trying to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain the 'domain' parameter or the expected structure of the 'signals' object. It only hints that signals relate to 'task signals', leaving both parameters under-specified and requiring the agent to infer too much.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Resolve') and resource ('normalized task signals') and identifies a concrete output ('task-regime key'), which helps distinguish it from generic siblings like athena_resolve. However, the heavy jargon ('HIVE/SWARM/PACK/FLOCK/HERD/POD') may obscure exact semantics for an agent unfamiliar with the domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as athena_regime_geometry_resolve or athena_resolve. The description only states what the tool does, not the conditions or input scenarios that should trigger its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose that stale or unverified shared state fails closed by default and that ties remain preserved, which are useful traits. However, it does not clarify side effects, permissions, or what a 'replayable routing-only successor baton' contains, leaving important behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with multiple clauses joined by semicolons, making it less accessible than a structured breakdown. It is not excessively long, but it is not front-loaded with a clear primary action; the main output (compile successor baton) appears at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no output schema, the description is incomplete. It does not describe the return shape, side effects, prerequisites, or how to interpret the 'successor baton'. The fail-closed statement adds operational context, but an agent lacks enough detail to invoke the tool correctly or understand the full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29%, and the description does not map its concepts to parameters. Terms like 'loop state digest' indirectly hint at expected_state_digest, but loop_id, policy, candidates, and completion are not explained in the description. The description fails to compensate for the schema's sparse documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description breaks down a multi-step operation (fresh-sync Git, verify digest, apply terminal gate, compile successor baton) with a specific verb+resource. However, terms like 'successor baton' and 'loop state digest' are domain jargon, and the tool is not clearly differentiated from siblings like athena_cycle_advance or athena_rehydration_advance except for the 'routing-only' qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs. alternatives. The reference to 'the same witnessed terminal-closure gate used by advance' is a behavioral note, not a usage recommendation. The description does not mention when a successor preview is needed over a full advance or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of disclosing side effects. It does mention updating a persistent witness, which indicates a write operation, but it does not explain what the witness is, whether the operation is reversible, or what permission or state requirements exist. It also does not describe the return value or any errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the key action. It contains no filler or redundant information, making it efficient and well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has six parameters, no output schema, and no annotations, the description is too minimal. It does not explain required fields like plan_key, nor does it describe return values or behavioral expectations. The description is insufficient for an agent to confidently invoke the tool without additional schema or documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only clarifies the roles of predicted_rgo and observed_rgo by naming them as 'predicted versus observed Return-on-Group-Organization'. With schema description coverage at 0%, it fails to explain the purpose of actor, scope, features, and plan_key. The description adds some semantic value for two parameters but is largely insufficient for the six-parameter schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: recording predicted versus observed Return-on-Group-Organization and updating a persistent witness. It uses a specific verb ('Record') and resource, making the purpose unambiguous. It does not explicitly distinguish from sibling tools like athena_rgo_calibrate, but the core action is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. The context is minimal—only that it records observations—but no explicit usage conditions are given. Sibling tools such as athena_rgo_calibrate and other observe tools could be confused without more guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects and mutation behavior. It mentions 'evaporation' as a decay mechanism, but does not state that the tool modifies state, what the return value is, or whether changes are reversible. This is insufficient for a state-updating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the primary action and target. It is concise and contains no filler, though it is dense with domain jargon.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (5 top-level parameters, a nested observations object with 8 fields, no output schema, and no annotations), a one-sentence description is entirely inadequate. It fails to explain how to construct inputs, what the tool returns, or the semantics of the evaporation process.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by mapping evidence, reuse, downstream, age, staleness, and contradiction to the update logic, which partially compensates for the 0% schema coverage. However, it does not explain deposit_gain, evaporation_rate, current_score, or the structure of the observations object, leaving key parameters under-defined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific action (update artifact/routing priority) and outlines the mechanism (reinforcement plus evaporation). This distinguishes it from simpler reinforcement tools like athena_pheromone_reinforce, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling reinforcement/pheromone tools. The description explains what it does, but not the selection criteria or context that would call for this tool specifically.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose side effects and operational behavior. It states that the tool 'Return[s]' outputs, implying a read-only computation, but never explicitly says it does not modify state, requires prior data, or how calibration is performed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action and output; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 optional parameters, no output schema, and no annotations, yet the description provides no usage context, parameter semantics, or behavioral detail. It is a minimal one-liner that leaves key invocation questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and no parameter descriptions, the description must explain the parameters. It only hints at target_coverage via 'coverage' and 'Bayesian intervals', but scope, arm_id, and regime are never explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Return' and identifies the exact outputs: empirical coverage/error/width and a reliability-shrunk sigma correction for Bayesian intervals. This clearly distinguishes it from unrelated sibling tools, though it does not explicitly differentiate from similar calibration tools like athena_rgo_calibrate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus other calibration or Bayesian interval tools. There are no exclusions, prerequisites, or references to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must independently disclose behavioral traits. It only states that the tool creates a variant, implying a mutation, but does not specify whether this is read-only, destructive, or involves side effects on the parent. It also fails to mention any requirements like the parent must exist or whether the operation is reversible, leaving critical behavioral information undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words, making it concise. However, it is under-specified for the tool's complexity, sacrificing necessary information for brevity. While there is no fluff, the description is not appropriately sized for a tool with 10 parameters and nested objects, as it lacks detail that would be essential for correct usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, 4 required, nested objects) and the absence of an output schema and annotations, the description is grossly incomplete. It does not define what a 'variant' entails, how the parent family is determined, or the roles of detector and repair. The description covers only a fraction of the context needed to invoke the tool effectively, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 10 parameters with 0% description coverage, placing a heavy burden on the tool description to explain them. The description only hints at 'parent_id' via 'parent's family' and 'ttl_hours' via 'optional expiry', but it does not explain the other required parameters such as 'signature', 'detector', or 'repair'. This minimal compensation is insufficient for an agent to understand how to populate the parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: creating a distinct antibody variant within a parent's family. The verb 'Create' and the resource 'antibody variant' are specific, and the mention of 'parent's family' distinguishes it from sibling tools like athena_antibody_select or athena_antibody_record_outcome, which focus on other aspects of the antibody lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or alternative tool names. For instance, it does not clarify when one should choose 'evolve' over 'select' or 'register', leaving the agent to infer the use case from the tool's name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. It does reveal a non-obvious behavior: closed routes automatically measure holonomy only when all edges are derivational, and LOOKUP-containing loops are marked N/A rather than promoted. This adds useful context beyond a basic 'apply route' statement, but it lacks details on side effects, permissions, error cases, or what happens for open routes, so transparency is only moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff, and the primary action ('Compose and execute') is front-loaded. Each clause adds meaningful information, particularly the edge-case handling for closed routes. However, the heavy use of domain jargon and compact notation may hinder readability, but it's appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description needs to explain what the tool returns and the expected input format beyond the schema. It explains the closed-route behavior but doesn't mention return values, how a route should be specified as an array of strings, or any prerequisites. For a tool with 4 parameters and a non-trivial concept, this description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining parameters. The description references 'coordinate route' and the C_i0->...->C_ik notation, but it doesn't explain the role of subject_id, route contents, actor, or source_value. No parameter semantics are provided, leaving the agent to guess the meaning and format of each property, especially the route array elements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Compose and execute a coordinate route' with a specific path notation C_i0->...->C_ik. This indicates it handles sequences of transforms, distinguishing it from single-transform tools like athena_apply_transform. However, it doesn't explicitly name alternative tools or when to prefer this one, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for executing coordinate routes and includes guidance on how closed routes are handled (holonomy only for derivational edges, LOOKUP-containing loops marked N/A). It gives context on the behavior that users can expect, but it doesn't explicitly state when to use this tool vs. alternatives or provide exclusion criteria, so guidance is mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds some context: 'Exactly solve' indicates a computational operation, and 'PLAN_ONLY' tells the agent it only produces a plan. However, it doesn't disclose return values, side effects, required prerequisites in detail, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action and includes a mode tag. It is compact but the conditional clause 'when the full joint model-state tree completes' is jargon-heavy and could be better structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 6 parameters, nested objects, and no output schema, this 18-word description leaves too many unknowns: what is returned, how parameters interact, what 'full joint model-state tree completes' means operationally, and how long solving may take.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation for the six parameters (states, initial_state_belief, models, horizon, discount, max_nodes). Terms like 'static uncertain model index' loosely map to 'models', but no practical guidance is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Exactly solve a bounded finite-horizon POMDP with a static uncertain model index', providing a specific verb and resource. The 'PLAN_ONLY' tag distinguishes it from execution-oriented tools, and the 'static uncertain model index' differentiates it from sibling athena_pomdp_solve.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives are named. The phrase 'when the full joint model-state tree completes' indicates a prerequisite condition but not a usage recommendation. The many sibling tools (e.g., athena_pomdp_solve, athena_contingent_policy) are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. 'PLAN_ONLY' usefully signals that the tool does not execute actions, and 'one-step' indicates the planning horizon. However, it does not state whether the planning has side effects (e.g., storing plans), how results are returned, or any permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, with the 'PLAN_ONLY' flag prominently front-loaded. It is efficient and free of filler, but the term 'finite-belief controller' is jargon that could be expanded slightly without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a dual-control solver with five parameters, no output schema, and no annotations, this description is too terse. It omits the meaning of parameters, the nature of the output (a plan?), and how this tool relates to similar siblings. An agent would have difficulty invoking it correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not compensate. It hints at the roles of risk_weight and information_weight via 'utility' and 'information value', but it does not explain context_key, actions, or discount. Parameter names give partial clues, but the description adds little to what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a 'one-step finite-belief controller' that combines immediate utility, expected next decision utility, and information value. This gives a specific algorithmic role and differentiates it from multistage or general control tools, though the verb is implied rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like athena_dual_control_plan or athena_belief_policy_multistage. The 'PLAN_ONLY' tag hints at a planning-only scope, but there is no explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full weight but only mentions 'register/reset' and 'normalized priors.' It does not disclose side effects, whether existing state is overwritten, permissions, error behavior, or return values. The note about non-canonical truth is abstract, not operational.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, but overly terse. It wastes no words, yet the second sentence ('Model belief is not canonical truth') is a philosophical caveat that may be less valuable than explaining key aspects of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema, this description is incomplete. It lacks critical details about what 'models' contains, how 'context_key' scopes the state, what 'replace' does, and what success/failure responses look like. The provided context is minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain 'context_key', 'models', or 'replace'. The word 'reset' hints at the replace boolean but is far from explicit, leaving the agent to infer parameter meaning from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is specific with a clear verb ('register/reset') and resource ('finite discrete model belief state'), and adds detail about normalized priors. It distinguishes from the sibling tool athena_gaussian_belief_register by specifying 'finite discrete' vs. Gaussian.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finite discrete models, contrasting with Gaussian belief tools, but does not explicitly mention alternatives or provide when-not-to-use guidance. The caveat about non-canonical truth hints at epistemic context but lacks clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does mention that the output is 'stable' and warns against interpreting stability as causal probability, but it does not address side effects, computation cost, or data format expectations. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core action and output, the second adds an important interpretive caveat. There is no wasted verbiage, and the structure is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 parameters, no annotations, no output schema), the description is too sparse. It omits parameter semantics, expected input format, and detailed behavioral outcomes, leaving significant gaps for an agent attempting to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description does not explain any of the 6 parameters (e.g., samples, resamples, thresholds). The agent receives only type/range constraints with no semantic meaning, making it impossible to set appropriate values without external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Bootstrap') and the specific resource ('V7 heuristic association skeleton'), and specifies the output ('stable undirected/v-structure candidates'). This distinguishes it from sibling causal tools that may return different structures, and the caveat 'Stability is not causal probability' further clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like athena_structural_bootstrap_ensemble or athena_pc_stable_discover. It does not state prerequisites, exclusions, or typical use cases, leaving the agent to infer from the name only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that it lists and optionally filters, but doesn't describe return format, side effects, or any constraints. Since it's a read-only list, the lack of any mention of safety or limits is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded, no filler. It is appropriately concise, though it could be slightly more informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or output schema, the description provides only minimal context. The cryptic 'Y', the meaning of enum values, and the behavior of the limit parameter are unaddressed, making it insufficient for an agent to fully understand the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly identifies 'y' and 'status' as filter parameters, adding meaning to the schema. However, it doesn't explain the enum values for y or status, nor mention the limit parameter. With 0% schema coverage, the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and resource 'claim authority heads', clearly naming the operation. It also mentions optional filtering, distinguishing it from claim mutation tools like athena_claim_challenge or athena_claim_promote, though the term 'authority heads' is somewhat cryptic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention any exclusions or conditions, though the filtering options imply usage for listing claims with specific statuses. Missing explicit when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the action requires explicit authorization and that the decision must be UPHOLD or DEMOTE, giving some sense of governance. However, it does not state side effects on the claim, reversibility, return value, or failure conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and key concepts with no padding. It is appropriately concise, although the extreme terseness leaves some gaps that are penalized in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a governance mutation tool with a nested authority object, no output schema, and no annotations. The description does not mention what happens to the claim, what the tool returns, or how it fits into the challenge workflow, so an agent lacks sufficient context for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for 'decision' by naming the UPHOLD/DEMOTE options and for 'authority' by mentioning authorization, but it leaves claim_id and actor completely unexplained. This is only partial compensation for the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific governance action: resolving claims in the CANONICAL_CHALLENGED state via UPHOLD or DEMOTE. It uses a specific verb and resource, and distinguishes it from claim_challenge by addressing resolution rather than creation, though it does not name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The phrase 'explicit authorized governance' implies a formal decision context, but there is no mention of alternatives like athena_claim_challenge or athena_claim_promote, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 adds a useful behavioral detail: allocation is driven by demand × capability fit × available capacity, which clarifies the decision logic. However, it does not disclose whether the tool mutates state, what it returns, or any side effects, leaving important behavioral aspects ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one clear, front-loaded sentence with no filler. It is efficient but perhaps too terse for a tool with multiple parameters and no annotations, as it omits essential details. Still, it earns a high mark for brevity and directness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, no output schema, no annotations), the description is incomplete. It does not explain what the tool returns, how to interpret the output, the effect of alpha/beta, or constraints like max_assignments_per_worker. This is a significant gap for a tool that likely produces a nontrivial allocation result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the five parameters (tasks, workers, beta, alpha, max_assignments_per_worker). The formula mentioned aligns conceptually with task/worker properties but does not clarify parameter roles or types. This fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: allocate tasks using a specific formula (demand × capability fit × available capacity). It uses a specific verb ('allocate') and resource ('tasks'), and distinguishes itself from equal participation, but it does not explicitly name or differentiate from sibling tools like athena_collective_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case (when tasks need allocation based on fit rather than equality) but provides no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It does not mention any context or scenarios where this tool is preferred over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals algorithmic behavioral traits (cross-inhibition, contradiction blocking, risk-dependent threshold, required winning margin) but says nothing about side effects, permissions, or return values. With no annotations provided, the description carries the full burden of behavioral disclosure and fails to clarify whether the tool mutates state or is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence efficiently packs the core functionality and key constraints. It front-loads the verb 'Run' and then lists behavioral specifics without unnecessary filler. The jargon-heavy phrasing makes it less accessible, but the structure is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and the description does not explain the return value or side effects. Given the complexity of the quorum selection algorithm, an agent would be unsure what to expect after invocation. More context is needed on the result format and any prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description references concepts like 'cross-inhibition,' 'contradiction blocking,' and 'risk-dependent threshold' that map to schema properties (inhibition, contradiction, risk, etc.), but it does not explicitly name parameters or explain their exact formats. With 0% schema description coverage, this partial semantic mapping helps but does not fully compensate for missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Run') and the specific resource ('evidence-sensitive quorum selection'), with distinctive algorithmic constraints such as 'cross-inhibition' and 'contradiction blocking'. It stands apart from sibling collective_* tools by focusing on quorum selection with consensus rejection. However, the heavy jargon may reduce clarity for agents without domain knowledge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given for when to use this tool versus alternatives. The phrase 'consensus alone cannot commit' implies a context, but it never mentions sibling tools, prerequisites, or exclusions. An agent would have to infer usage from the name and description, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses a key trait: the planner is plan-only and requires the agent to execute just the first action then replan. However, it does not mention whether the tool has side effects, what it returns, or any required setup, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at two sentences with no redundant phrasing. However, the first sentence is dense with jargon and the second is an imperative rather than a descriptive explanation, making it less effective than a slightly longer, clearer version would be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (8 parameters, no output schema, no annotations), the description is far too sparse. It provides a high-level concept but lacks operational details on how to set parameters, what results to expect, or how to integrate the planned actions. An agent would likely struggle to invoke this correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the 8 parameters. It mentions conceptual elements like 'control reward', 'transition-parameter information value', and 'predictive risk', which loosely map to discount, information_weight, and risk_aversion, but it never explicitly ties these to the schema fields. Parameters like initial_context, actions, horizon, and beam_width are left entirely undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a 'dual-control planner' with a specific combination of objectives (control reward, information value, predictive risk), which distinguishes it from broader planning tools. The 'PLAN_ONLY' tag adds clarity but 'bounded proxy' remains unexplained, and it does not explicitly contrast with closely related sibling tools like athena_belief_dual_control.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state when to use this tool over alternatives, nor does it mention exclusions. The instruction 'PLAN_ONLY; execute first action then observe/replan' gives some operational guidance but is more behavioral than a usage guideline, and no alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Return', giving no detail on side effects, preconditions like an existing fitted model, error handling, or whether the operation is read-only. This is insufficient for safe agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no redundancy. It is front-loaded with the core action and ends with a clarifying tag, making it efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, a nested object, no output schema, and no annotations, this description is far too sparse. It omits parameter meanings, expected return structure, and any usage context, leaving major gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the four parameters (l2, scope, features, confidence_z). The agent receives no meaning beyond the raw schema field names, making correct parameter construction guesswork.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a Laplace/Hessian logit interval for a fitted V10 evidence-dependence probability. The action verb 'Return' plus the resource and method specificity distinguish it from sibling tools like probability, predict, and fit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are provided. The phrase 'Model-conditional diagnostic' vaguely implies use after model fitting, but there is no guidance on prerequisites, exclusions, or why this tool over the many sibling evidence-dependence tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the safety/behavioral burden. It discloses that the model is 'caller-declared' (vs fitted) and that it is diagnostic, which is useful. But it does not state whether the tool is read-only, what side effects (if any) exist, what the output format is, or how failures are surfaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and contains no filler. It is appropriately concise, though it sacrifices necessary detail for brevity, so it is not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a specialized statistical tool with 4 parameters, a nested object, no output schema, and no annotations. The description gives only a high-level purpose and a diagnostic caveat. It is far from complete: it lacks parameter semantics, expected outputs, error conditions, and guidance relative to the many sibling dependence tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides almost no parameter-level detail. Terms like 'caller-declared logistic model' vaguely hint at 'coefficients', but claim_id, dimensions, coefficients, and min_confidence are all unexplained. An agent cannot correctly construct the coefficients object or know what min_confidence does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Apply... model') and the target ('science-shadow witness pairs'). It also adds a useful qualifier ('Diagnostic, not formal independence inference') that helps distinguish this from a formal test. However, it doesn't explicitly say the result is a probability, relying on the tool name for that key semantic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Diagnostic, not formal independence inference' provides a when-not-to-use warning and implies a diagnostic context. However, it does not name alternative tools or mention concrete scenarios where this should be preferred over siblings like athena_evidence_dependence_fit or athena_evidence_dependence_observe.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It states 'Fetch' (implying a read operation) and mentions 'all task heads', but it does not describe return format, side effects, permissions, or any other behavioral context. The word 'fetch' is a weak implicit indicator of safety, but the description lacks substantive disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and front-loaded with the key action, making it appropriately concise. However, it is slightly under-specified, so it earns a 4 rather than a 5 because every sentence should earn its place but here it does not carry enough informative weight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should explain what is returned. It mentions 'task heads' but not their structure or how they support replay/navigation. With one parameter and no annotations, a simple fetch tool still needs more detail about return values and use context to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'run_id' with 0% description coverage, and the description does not mention it at all. While the parameter name is somewhat self-explanatory, the description adds no semantics about its format, origin, or constraints beyond the schema's 'minLength: 1'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and identifies the resource as 'one extraction run' with the additional detail 'all task heads', making the action clear. It does not explicitly distinguish from sibling tools such as athena_extraction_result or athena_extraction_task, but the replay/navigation context provides some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for replay/navigation' implies the tool is intended for those use cases, but there is no explicit statement of when to use it versus alternatives or any exclusions. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It does explain the algorithm's bounded and limited propagation aspects, which is useful. However, it does not mention side effects, return format, or computational constraints, leaving important behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The first sentence is dense but packs in the core algorithm details; the second clarifies scope. It is appropriately concise for the technical content, though jargon-heavy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex causal discovery tool with no annotations, no output schema, and 0% parameter documentation. The description does not clarify what a 'partial ancestral candidate' looks like as a return value, how samples should be formatted, or what 'bounded' means in practice. Incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description's phrase 'conditioning subsets up to a declared order' maps loosely to max_conditioning, but it does not explain samples, variables, or alpha. With 0% schema description coverage, the description fails to compensate for the complete lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a concrete action ('Build a bounded FCI-inspired partial ancestral candidate') and defines its scope (conditioning subsets up to declared order, collider orientation, limited propagation). It distinguishes itself from full FCI/RFCI, though it does not explicitly name sibling tools like athena_pc_stable_discover or athena_pag_candidate_discover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The phrase 'Not full FCI/RFCI' implies it is a lighter-weight option, but there is no mention of use cases, prerequisites, or comparison to sibling discovery tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose safety and behavioral traits. It describes the comparison and outcome but doesn't state whether the tool is read-only, what it returns, how 'material' is determined, or any error/edge-case behavior. This leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the core action. However, its brevity sacrifices some clarity for an unfamiliar audience, though it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters and no output schema, this description is too sparse. It fails to explain return values, the meaning of key terms, or how to interpret the result, making it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 8 parameters, the description only indirectly maps to three expected digests (source_head, frontier_digest, prompt_stack_digest) and omits the other five parameters (task, fetch, remote, profile, source_ref). It provides no parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific comparison operation across three named resources (shared source head, frontier digest, prompt-stack digest) and states a consequence. However, it doesn't explicitly distinguish from sibling tools like athena_prompt_freshness or athena_rehydration_verify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is used to detect material coordinate changes that require rehydration, but it doesn't explicitly state when to use it versus other freshness/hydration tools, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects and state changes. It mentions 'optional CAS application to current GP model' but does not explain what CAS entails, whether the tool is destructive, what state changes occur when 'apply' is true, or any permission requirements. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that leads with the main action. It avoids verbosity, though the unexplained 'CAS' acronym introduces some ambiguity without extra length. Overall it is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 6 parameters, no annotations, and no output schema, so the description must carry substantial contextual load. It does not explain return values, the effect of the 'apply' flag, the role of context_key, or the significance of the hyperparameter arrays. The description is insufficient for an agent to invoke the tool safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds minimal detail about the parameters. It references 'hyperparameters' generically but does not explain the meaning of length_scales, noise_variances, signal_variances, apply, expected_observation_count, or context_key. The description fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: grid-searching fixed RBF GP hyperparameters via exact marginal likelihood. This identifies the verb, resource, and method, and distinguishes it from sibling GP tools (e.g., hyperposterior, hyperqmc) that address different inference tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description implies it is for hyperparameter search but does not explain scenarios where another tool would be preferred or how to decide between grid-search and other hyperparameter approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what the tool computes (ranking policies) but does not state whether it is read-only or has side effects, what the output format is, or any computational caveats. The 'PLAN_ONLY' hint is vague and does not clarify potential behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, about 20 words, that front-loads the primary action and then lists the ranking criteria. It is efficient but 'PLAN_ONLY' is cryptically appended, which slightly hurts clarity. Still, it earns its place without wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no output schema, no annotations), the description is insufficiently complete. It does not explain key concepts like 'bounded weighted joint-state ensemble', parameter relationships, or expected return format. The tool's rich sibling context (e.g., policy_score, pareto_frontier) is not addressed, leaving the agent without enough context to ensure correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. While it lists criteria like 'lower-tail CVaR' and 'expected/max regret', it does not explicitly map these to the parameters (e.g., cvar_alpha, cost_weight, risk_weight, regret_weight). The meaning of cost_weight and risk_weight remains ambiguous, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Rank policies' over a 'bounded weighted joint-state ensemble', specifying multiple ranking criteria. This is specific and likely distinguishes it from other policy tools, though it doesn't explicitly name any sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use of 'PLAN_ONLY' provides a contextual constraint, implying this is for planning-phase analysis only. However, there is no explicit guidance on when to use this tool versus alternative policy-ranking or evaluation tools, and no mention of exclusions beyond the planning context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the method but does not mention side effects, required assumptions in detail, what the output looks like, or any constraints on inputs. 'Assumption-scoped' hints at assumptions but is too cryptic to be informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the key action ('Estimate'). The second sentence, 'Assumption-scoped,' is compact but vague, arguably not earning its place since it adds incomplete information. Overall, it wastes few words but sacrifices clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, nested objects, no output schema, no annotations), the description is too minimal to be complete. It does not describe return values, assumption requirements, sample data structure, or how to specify regimes. This leaves significant gaps for an agent deciding whether and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 8 parameters with zero description coverage in the schema. The tool description compensates only partially: it clarifies the role of 'intermediate' (binary) and implies 'treatment1'/'treatment2' correspond to time points, but leaves 'samples', 'regimes', 'baseline', and 'assumptions' unexplained. This is insufficient for an agent to confidently construct parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Estimate static two-timepoint treatment-regime risks' via a 'transparent parametric g-formula.' It also specifies the scope (over one binary intermediate variable), which distinguishes it from related longitudinal tools like athena_longitudinal_tmle, which use different estimation approaches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to choose this tool over alternatives. The phrase 'Assumption-scoped' is vague and does not explain which assumptions (e.g., no unmeasured confounding, positivity) make this approach appropriate, nor does it name alternative tools for different scenarios. Without this, an agent lacks clear direction on use cases versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It usefully discloses that the operation is 'lossy' and that it 'retains residue/provenance' and 'never asserts cultural identity/equivalence,' which are important behavioral traits. However, it omits other behavioral details like return format, side effects, or handling of unmapped fields, so transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, with the core action front-loaded. However, the unexplained acronym 'MMTB' and dense jargon (residue/provenance, cultural identity/equivalence) reduce clarity, though there is no wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters (including nested objects) and no output schema or annotations, a one-sentence description is insufficient. It doesn't cover return values, behavior for unmapped fields, or examples, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does not explain any parameter explicitly; 'field transport' hints at field_map but doesn't clarify the roles of source_model, target_model, invariants, source_ref, or target_ref. The parameter names are self-evident but the description adds little.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it performs 'explicit lossy field transport between scoped models,' indicating a specific operation with a clear resource and scope. It also adds distinguishing constraints ('retain residue/provenance and never assert cultural identity/equivalence'), which differentiates it from sibling transport tools. However, the jargon ('scoped models', 'field transport') is not plainly explained, so it's not fully clear to an agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It mentions constraints but not use cases, prerequisites, or exclusions. No sibling alternatives are named, leaving the agent to guess when 'lossy field transport' is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the tool preserves provenance/loss and does not invent matches, which are useful traits. However, it does not clarify side effects, output format, or whether it mutates state, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence and front-loads the core idea. It is concise and avoids redundancy. However, the unexplained 'SAC:' prefix and dense jargon reduce clarity, so it is not as efficient as it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a nested address_space structure, the description is incomplete. It does not describe return values, behavior on no match, or the meaning of fields within address_space items (e.g., standing, terms). The tool is under-specified for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only hints at 'address_space' as the symbolic address space, but it says nothing about 'query' or 'context'. With 0% schema description coverage, the description should compensate, but it does not provide enough meaning for the parameters, so it is weak.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('select') and resource ('caller-supplied symbolic address space'), and it suggests a clear behavioral distinction ('HOLD rather than invent a match'). However, the acronym 'SAC' is unexplained, and the phrasing is jargon-heavy, so it is not maximally clear to a non-expert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for selecting from a caller-supplied address space, but it offers no explicit guidance on when to use this tool versus alternatives, nor when not to use it. No sibling tools are referenced, and no context conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the algorithmic approach (ridge-regularized Mahalanobis geometry, unseen-feature pressure) but does not disclose whether the operation is read-only, what output format is returned, whether it requires any special permissions, or any side effects. This is insufficient for a scoring tool where safety and return details matter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the operation ('Score a context') and packs the algorithm details efficiently. There is no redundant wording, and it is appropriately sized for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex statistical tool with 4 parameters (including a nested object), no output schema, and no annotations. The description omits return value format, parameter details, usage context, and any behavioral caveats. For such a tool, the description is severely incomplete and would leave an agent guessing about invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implicitly maps 'context' to the features parameter and 'regime distribution' to the regime parameter, but it does not explain the 'ridge' or 'scope' parameters. The reference to 'ridge-regularized' hints at the purpose of the ridge parameter but does not define it; 'unseen-feature pressure' is ambiguous. With four parameters and no schema descriptions, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a scoring operation for context against an empirical regime distribution, using a specific algorithm (ridge-regularized Mahalanobis geometry plus unseen-feature pressure). It includes a specific verb ('score'), a resource ('context'), and a method, making the purpose unambiguous and distinguishable from generic observability or prediction siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It simply states what the tool does, leaving the agent to infer usage context. No alternative tools are named or compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only computation on an existing run ('persisted orchestration run') but does not explicitly state whether it has side effects, requires specific permissions, or returns structured output. This lack of behavioral detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to stating the tool's core function, achieving maximal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and low parameter coverage, the description is insufficiently contextual. It does not explain what 'successor rank sensitivity' means, what the output looks like, how relative_perturbation works, or any operational context, leaving the agent with sparse guidance for a likely domain-specific analysis task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention either parameter. It only implies the run_id via 'one persisted orchestration run' but fails to explain the optional relative_perturbation parameter or how it affects the computation. The description adds no value beyond the schema, which itself lacks descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Compute') and a specific resource ('successor rank sensitivity for one persisted orchestration run'). This clearly distinguishes it from sibling tools like athena_orchestration_get or athena_causal_robustness by defining the exact analysis scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It merely states what it computes, leaving the agent to infer usage context. No exclusions, prerequisites, or comparison to sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It does reveal a notable side effect (synchronizing the Message Board frontier) that goes beyond a simple list operation, but it does not elaborate on the nature of the synchronization, safety, or potential return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. However, its brevity sacrifices critical details, making it more under-specified than concise in the sense of being complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three optional parameters, a side effect, and no output schema, the description lacks essential context. It does not explain what 'Git-shared parties' are, what 'Message Board frontier' means, or what the returned list contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero schema description coverage and no mention of the three parameters (limit, remote, shared_remote_mode) in the description, the agent cannot infer what these parameters control. The description provides no semantic value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists Git-shared parties, and adds a specific precondition/behavior of synchronizing the Message Board frontier. This distinguishes it from other party-related tools that might just observe or join, though it does not name a specific alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'after synchronizing the Message Board frontier' implies a sequencing requirement, but there is no explicit guidance on when to choose this tool over sibling tools like athena_party_observe or athena_party_state. It also does not explain what to do if synchronization is not needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states 'persistently reinforce or evaporate,' which indicates a mutation with persistence side effects, but it fails to explain whether the operation is reversible, what permissions are needed, or what happens to existing pheromone values. The description provides minimal transparency about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes no words. It efficiently conveys the core action and the nature of the observations. The only slight issue is the word 'persistently,' which may be ambiguous, but overall it is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters, no annotations, no output schema, and a nested object, this description is far too sparse. It does not explain parameter semantics, side effects, return values, or how to distinguish this tool from its many siblings. An agent would struggle to invoke it correctly based only on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining parameters. It adds some context for 'observations' by listing evidence, reuse, novelty, staleness, and contradiction, but leaves deposit_gain, evaporation_rate, age, actor, and route_key entirely unexplained. This is insufficient for a 6-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (reinforce or evaporate) and the resource (artifact/routing pheromone), using specific terms like 'evidence, reuse, novelty, staleness and contradiction observations.' However, it does not explicitly differentiate from sibling tools such as athena_pheromone_adaptive_reinforce or athena_pheromone_multiscale_reinforce, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The mention of specific observation types implies this tool is used when you have those observations and want to update a single pheromone. But there is no explicit guidance on when to use it versus alternatives, no prerequisites, and no exclusions, leaving the usage context only implied rather than clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the conditional behavior: if the node search doesn't complete, no certificate is returned. This is a meaningful behavioral trait. However, it does not state whether the tool has side effects, requires authentication, or what 'no certificate' precisely means, leaving ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and free of filler. It front-loads the core purpose and includes the conditional caveat. The only weakness is that it is arguably too terse, omitting necessary context, but for conciseness itself it scores well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, nested objects, no output schema, and no annotations, this description is grossly incomplete. It fails to explain parameter roles, return value structure, or use conditions, making it impossible for an agent to correctly invoke the tool without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides no parameter explanations. It mentions 'finite-state' and 'finite-horizon' which loosely relate to states and horizon, but it doesn't define the required parameters (states, actions, initial_belief) or optional ones (horizon, discount, max_nodes). The agent can't infer parameter semantics from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an exhaustive solver for a finite-state finite-horizon POMDP tree, with a conditional success criterion. It distinguishes from sibling solve tools by emphasizing 'small' and the node-search dependency. However, it leaves 'node search' undefined, which slightly obscures the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a precondition (node search must complete) and a fallback (no certificate). This gives some guidance on when the tool succeeds, but it does not state when to choose this over sibling solvers like athena_bapomdp_solve. No explicit alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It does surface several non-obvious behaviors: it only applies to 'active' JSPACE edges, uses 'semantic-head CAS' (suggesting compare-and-swap semantics), and explicitly excludes Git compensation. However, it does not disclose whether the inverse removes edges, disables them, or restores a prior state, nor does it mention any destructive consequence or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. The second sentence about Git compensation adds useful boundary information without being verbose. It loses a point because the heavy use of domain jargon reduces readability, but it is still economically written.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (mutation, no annotations, no output schema, dense domain vocabulary), the description is not complete enough. It omits what a 'projection' is, what 'compensate' concretely does to the topology, how CAS interacts with expected_semantic_eid, and what the caller should expect post-invocation. The presence of many sibling tools further raises the need for clearer context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of inline parameter documentation. It only implicitly ties 'projection_id' to the phrase 'created by one topology projection'; it does not clarify 'expected_semantic_eid' (presumably the CAS token) or 'actor'. This is insufficient for an agent to correctly build a request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('apply the explicit semantic inverse') and the target resource ('active JSPACE edges created by one topology projection'), which distinguishes it from sibling tools like athena_projection_prepare. The context 'under semantic-head CAS' adds specificity, though the jargon may limit clarity for general-purpose agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives like athena_projection_prepare, athena_topology_rollback, or athena_topology_apply. The only usage hint is the offhand note that 'Git compensation remains separately surfaced,' which implies a division of responsibilities but does not explain the broader workflow or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses one behavioral consequence (global classes require adoption next cycle), but omits other side effects, permission requirements, or what happens with non-global classes. The provided detail adds some value but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the primary action, and contains no filler. It is concise and easy to parse, though it could be expanded to include essential details without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description is insufficient. It does not explain return values, parameter formats, or the full lifecycle of a mutation registration. The single behavioral note is helpful but leaves many operational aspects undisclosed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the parameters (mutation_class, payload, source_eid, actor). There is a vague reference to 'global classes' which hints at mutation_class, but no concrete semantics are provided, leaving the agent to guess parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Register a discovered mutation', with an added detail about global classes requiring adoption. It identifies the tool's core purpose, though it does not differentiate from sibling tools like athena_adopt_mutation or athena_pending_mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: global mutation classes trigger adoption by all active agents next cycle. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It adds useful context about the tool covering both 'historical PROMOTION.1 and current PROMOTION.2 semantics', which explains a non-obvious behavior. However, it does not disclose other important traits such as read-only nature, default limit, ordering, or pagination, so it only partially compensates for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, direct, and front-loaded with the verb 'List'. It contains no filler words and conveys the core purpose efficiently. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description is too sparse to be complete. It does not explain what a 'receipt' is, what the output looks like, the meaning of 'unified runtime promotion receipts', or how the limit parameter affects results. An agent would likely need additional information to use this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its only parameter 'limit', and the description does not mention it at all. With such low schema coverage, the description was required to compensate but fails to explain the parameter's meaning, default behavior, or impact. The parameter name is self-explanatory to some degree, but the description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List recent persisted unified runtime promotion receipts', which includes a specific verb and resource. It also adds scope by mentioning historical PROMOTION.1 and current PROMOTION.2 semantics, distinguishing it from other promotion-related tools like athena_promotion_get and athena_promotion_replay. However, it does not explicitly name or contrast with siblings, so it falls 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The description only implies a usage case via the word 'recent' but does not state prerequisites, exclusions, or alternatives. This is similar to the 'Update shared drive settings' example which received a 2 for lack of guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'deterministically compile' and 'ancestry/digest,' which add some context, but it does not state whether the operation mutates state, what it returns, or any side effects. The behavior remains opaque for an agent deciding whether to invoke it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with no filler or redundancy. It front-loads the main action ('Hydrate...') and preserves meaningful qualifiers like 'exact current' and 'deterministically.' Slightly more structure or examples could improve clarity, but it is appropriately compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, and with four parameters whose semantics are mostly unexplained, the description is incomplete. The agent is left without information about return values, prerequisites, side effects, or how the addendum is used. The tool's jargon-heavy context demands more elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the four parameters. It only hints that 'task/profile addendum' corresponds to the task and profile parameters, leaving include_text and previous_head completely unexplained. This is insufficient for proper parameter selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('hydrate', 'compile') and names the exact resource ('current Git prompt runtime') and output ('task/profile addendum with ancestry/digest'). This clearly distinguishes it from sibling tools like athena_hydrate or athena_frontier_hydrate by scoping to the Git prompt runtime and task/profile addendum.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus alternatives, no prerequisites, and no exclusions. The phrase 'exact current' implies a freshness requirement but does not explain when to choose this over athena_prompt_compile or rehydration tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool persists data, but it does not mention return values, idempotency, validation rules, failure modes, or required authorization—important for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the action and object front-loaded, making it compact and easy to scan. However, the dense jargon ('H_gamma', 'provenance event') and a reference to a field not present in the schema reduce its structural effectiveness slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, 5 required, no annotations, no output schema, and empty schema definitions for several properties, this description is insufficient. It does not explain key parameters, return behavior, or persist semantics, leaving an agent unable to confidently construct a valid invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate heavily. It names some fields ('start', 'returned state', 'defect', 'metric') and adds a 'provenance event' concept, but it omits required fields like subject_id and route, and the schema has no 'provenance_event' property, making the mapping confusing and incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Persist' and a precise resource ('measured closed coordinate-loop observation H_gamma'), clearly stating what the tool does. This distinguishes it from sibling record-style tools by naming the exact domain object and key persisted fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as athena_commit_delta or athena_register. There are no context cues, exclusions, or prerequisite conditions, so an agent receives no decision support for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It mentions 'uncertainty-preserving' as a property but does not disclose side effects, output format, reversibility, or any requirements. For a transform-like operation, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core function, and adds a useful caveat. Every word earns its place, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 6 parameters, no output schema, and no annotations, the description provides only a terse one-line conversion statement. It does not explain the graph representation, parameter relationships, or expected results, making it inadequate for correct invocation in most contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters are entirely undocumented in the schema. The description does not mention any parameter names, formats, or meanings, leaving the agent to infer from names like 'samples' and 'support_threshold' without any elaboration. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Convert V8 bootstrap association stability into an uncertainty-preserving o-o partial graph.' This clearly identifies the tool's function and resource. The negative clause 'Not FCI/PAG/CPDAG theorem' helps distinguish it from sibling causal discovery tools, though the jargon may be opaque to general agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying the input ('V8 bootstrap association stability') and what it is not ('Not FCI/PAG/CPDAG theorem'), but it does not explicitly state when to prefer this tool over alternatives or provide exclusions. The negative distinction gives a hint but no direct guidance on when to use or avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior. It indicates a mutation ('Record actual adoption') but does not mention side effects, idempotency, required permissions, or return values. The distinction from 'delivery/visibility' adds slight behavioral context but is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. It states the core action and provides a distinguishing qualifier, earning its place without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description provides the basic purpose but lacks critical context: when to use this over closely related sibling tools (like athena_promote_mutation), what constitutes 'adoption,' and any prerequisites. This leaves significant gaps in usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the parameters. While 'by an agent' and 'a global mutation' loosely map to the two parameters (agent, mutation_id), no details are given about format, semantics, or constraints, leaving the agent to infer from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Record' with a clear resource: 'actual adoption of a global mutation by an agent.' It also distinguishes itself from 'mere delivery/visibility,' which helps differentiate from potential sibling tools, though it does not name a specific alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'distinct from mere delivery/visibility' implies when this tool is appropriate (actual adoption, not just delivery), but there is no explicit statement of when to use it versus specific alternatives (e.g., athena_promote_mutation). No exclusions or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses that geometric nearest, global-envelope, and radius-eligible transport witnesses remain distinct and that the certificate is conditional on the declared bound. However, it does not state whether the operation is read-only, what side effects occur, or how results are returned, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two dense sentences with no filler, and both sentences contribute technical information. The second sentence is highly compressed and jargon-laden, which slightly harms readability, but overall it is concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 6-parameter tool with no annotations, no output schema, and 0% schema description coverage, this description is severely incomplete. It omits parameter semantics, return value, usage prerequisites, and any practical context, making it nearly impossible for an agent to invoke the tool correctly without additional external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain most parameters. It loosely maps 'witness pairs' to witnesses and 'caller-declared Lipschitz envelope' to lipschitz_bound, but parameters like feature_order, queries, margin_safety, and max_transport_radius are left entirely undefined, forcing the agent to guess their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Transport' and identifies the resource: 'witnessed approximation error' through a 'caller-declared Lipschitz envelope'. It is not tautological and references witness pairs, which helps distinguish it from generic transport sibling tools, though the jargon is heavy and may be opaque without domain knowledge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it is for transporting approximation error with a caller-declared Lipschitz bound and witness pairs. However, it provides no explicit when-to-use or when-not-to-use guidance and does not name alternative tools, so an agent has to infer context from the dense phrasing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses one behavioral trait: it preserves lineage and downstream dependencies during assignment. However, with no annotations provided, the description carries the full burden and fails to mention side effects, reversibility, permissions, or error conditions, making it incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the core function without unnecessary detail. It is front-loaded with the action and includes only essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex nested schema with multiple fields, yet the description provides no guidance on parameter usage, expected output, or edge cases. No output schema exists, so the description should compensate, but it does not, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the artifact properties (age, reuse, novelty, evidence, superseded, critical_lineage, downstream_dependents). The agent cannot determine how to construct the 'artifacts' array from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool assigns lifecycle states (KEEP_ACTIVE, KEEP_REFERENCE, etc.) to artifacts using the specific verb 'Assign'. It names exact state categories, which distinguishes it from sibling tools and provides a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks any context about scenarios, prerequisites, or exclusions, leaving the agent without selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full transparency burden. It only reveals that the tool lists states and can filter by three statuses, but does not disclose return format, pagination behavior, whether it is read-only, or any side effects. The tool name 'list' hints at safety, but the description does not explicitly confirm this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that contains no filler. It efficiently communicates the core action and the optional filter, earning its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema and no annotations, the description provides only the minimal action and filter. It lacks context about what branch lifecycle states actually are, what fields are returned, or how limit affects results, leaving gaps for an agent trying to invoke and interpret the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for the 'status' parameter by enumerating the allowed filter values (ACTIVE/HIBERNATED/REVIEW), but it does not explain the 'limit' parameter at all, leaving the agent to infer it controls result count from the schema's min/max bounds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('List') and resource ('branch lifecycle states'), and the optional filter values (ACTIVE/HIBERNATED/REVIEW) add specificity. It distinguishes from sibling tools like branch_state or branch_observe through the plural 'List' intent, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to enumerate branch lifecycle states, and the optional filter provides context for narrowing results. However, it does not explicitly state when to use this over sibling tools like branch_observe or branch_state, nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden, but it only states the accounting rule. It does not reveal whether the tool records data, returns a recommendation, mutates state, or has side effects—significant gaps for an 'account' tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with a clear action phrase followed by the decision criterion is efficient and front-loaded. It packs meaning without waste, though a slightly structured breakdown could aid readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 nested parameters and no output schema, the description omits expected return value, effect on system state, and relationship to nearby budgeting tools. The provided decision rule helps but leaves the invocation context under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description's conceptual mapping adds real value: it groups parameters into value (routing/reuse/quality/resilience) versus cost (build/maintenance/locked-capacity), interpreting the raw parameter names into a decision framework.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Apply living-bridge cost accounting') and a concrete decision rule ('build only when...'), which makes the tool's purpose identifiable and distinct from generic accounting tools. It doesn't explicitly contrast with sibling tools, but the 'living-bridge' framing differentiates it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used to decide whether to build based on cost-benefit, but it never states when to prefer this over sibling tools like athena_budget_record or athena_worker_cost_observe. No prerequisites, exclusions, or alternative scenarios are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It adds the important caveat that this is not a formal bound, but it does not explain what the tool returns, whether it mutates state, what prerequisites exist, or what 'V8' refers to.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary purpose and ending with a valuable caveat. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, low schema coverage, and a complex causal-inference context, the description is far too sparse. It fails to explain return behavior, parameter roles, or how to interpret the diagnostic result, leaving the agent without crucial contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only hints at the role of `adjustment` through 'leave-one-adjustment-out'. It does not explain `samples`, `treatment`, `outcome`, or `assumptions`, leaving most parameter semantics to the agent's inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific operation: a leave-one-adjustment-out robustness diagnostic tied to a V8 linear back-door estimate. This distinguishes it from sibling tools that estimate causal effects or identify causal structure, though the term 'V8' is unexplained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'around V8 linear back-door estimate' implies this diagnostic should be used after obtaining that type of estimate, and 'Not a formal hidden-confounding bound' warns against a specific misuse. However, no explicit alternatives or when-to-use instructions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states that the tool updates authority, which is a non-obvious behavior given the 'observe' name. However, with no annotations to fall back on, it omits details about state changes, idempotency, error conditions, or return behavior, leaving the agent underinformed about 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that front-loads the action and resource. Every word adds meaning, with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, a nested object, no annotations, and no output schema, this description is too sparse. It fails to convey the semantics of the outcomes object, the role of actor/scope, or the expected preconditions, making it insufficient for reliable invocation in an agent context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters, but it only indirectly references entity_id and outcomes. The optional 'actor' and 'scope' parameters are completely unexplained, and the structure of the 'outcomes' object is not described, severely limiting parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and identifies a clear resource ('longitudinal evidence-backed authority for an entity') with outcome sources. It distinguishes itself from many siblings by focusing on authority updates, though it doesn't explicitly name alternative tools or scope boundaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like athena_antibody_record_outcome or athena_credit_assign. The description gives no context about prerequisites, expected prior state, or situations where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds some behavioral context: the Hall of Immortals is 'chronological append-only', suggesting a read-only, immutable list. It also states a prerequisite ('fresh shared frontier sync'). However, with no annotations, it fails to disclose side effects, return format, pagination behavior, or error conditions, leaving significant transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words, making it efficient and front-loaded with the verb 'Return'. It is appropriately concise in form, though brevity comes at the cost of missing detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three optional parameters, no output schema, and no annotations, the description provides only a minimal outline. It fails to explain what the 'Hall of Immortals' is, what each parameter does, or what the return value contains, leaving the agent under-informed. The precondition 'fresh shared frontier sync' is mentioned but not defined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has three parameters (limit, remote, shared_remote_mode) with zero description coverage. The description provides no explanation of any parameter, leaving the agent to guess what 'remote' and 'shared_remote_mode' control. This is insufficient compensation for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Return' and identifies a unique resource ('P5 Hall of Immortals'), distinguishing it from all sibling tools which don't mention this concept. The phrase 'chronological append-only' clarifies the nature of the returned data. This is a clear, non-tautological purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a usage condition ('after a fresh shared frontier sync'), providing some context on when to invoke this tool. However, it does not mention alternatives, exclusions, or when this tool should be preferred over other retrieval tools. Thus, it relies on implication rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses useful behavioral traits: the alarm is 'bounded decaying,' dependency direction is reversed, and unknown relations are ignored. However, it does not state whether the tool mutates state, whether it is read-only, what triggers an alarm, or what the output format is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two dense sentences with no repetition or filler. The first sentence front-loads the core purpose, and the second adds necessary edge-case behavior. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five parameters, a nested object, zero annotation coverage, and no output schema, the description is not complete enough. It omits explanations for threshold, relation_modes behavior, side effects, and return values, leaving critical gaps for an agent selecting and invoking the tool. The high-level algorithm alone is insufficient for reliable parameter construction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it never explicitly names or explains parameters. 'Bounded decaying alarm' loosely maps to max_hops/hop_decay, and 'unknown relations are ignored unless explicitly mapped' hints at relation_modes, but seeds, threshold, and severity are not semantically enriched. The description adds algorithmic context but leaves most parameter meaning to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific operation: 'Compile typed JSPACE edges into an invalidation graph and propagate a bounded decaying alarm.' It names the resource (typed JSPACE edges) and the action (compile/propagate), which distinguishes it from generic graph tools. However, it does not explicitly differentiate itself from the similarly named sibling tool 'athena_dependency_alarm,' so it falls short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, and it does not name any sibling tools or exclusion scenarios. The only conditional information is the behavioral rule that 'unknown relations are ignored unless explicitly mapped,' which is a semantic detail, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions matching based on 'latest' data, but does not disclose whether this is a read-only operation, whether it triggers side effects, what it returns, or any prerequisites (e.g., agent existence). The lack of any behavioral details beyond a verb phrase leaves significant uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly conveys the core action and objects. Every word contributes meaning, and it avoids redundancy or fluff. It is an appropriate length for the tool's apparent simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should clarify what the tool returns (e.g., a list of offers or capability deltas) and any side effects. It does not. While the tool has only two parameters, the description still leaves important context unspecified, such as the nature of the result and any limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should compensate. The description gives some meaning to the 'agent' parameter (the agent whose needs/blockers are matched), but the 'limit' parameter is entirely unexplained. No parameter names or formats are mentioned, so the description only partially fills the gap left by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Match') with a clear resource ('an agent's latest needs/blockers against peers' latest offers/capability deltas'). It clearly states the matching function and distinguishes itself from sibling tools like athena_failure_antibody_match by focusing on agent needs vs peer offers, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the tool matches a specific agent's needs with peer capabilities. However, there is no explicit guidance on when to use this tool versus alternatives, no exclusions, and no situation-based direction. The word 'latest' suggests a temporal context but no direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior itself. It adds a key behavioral rule: 'unsupported OBSERVED/EMPIRICAL/HISTORICAL_PRIMARY and high-stakes symbolic use HOLD', which tells the agent when the tool will hold rather than promote. It does not disclose return format, side effects, or permissions, but the HOLD condition is meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, but it opens with the unexplained acronym 'ESCPF' and packs domain jargon ('standing', 'HOLD'). It is not overly long, but the brevity sacrifices clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a non-trivial tool with a nested `items` array, multiple enums, and no output schema or annotations. A single cryptic sentence does not explain what 'standing' means, what the output looks like, what 'HOLD' entails, or how use_case and requested_promotion influence the split/evaluation. Significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It connects only loosely to parameters: 'split claims' hints at `items`, 'explicit promotion requests' maps to `requested_promotion`, and 'high-stakes symbolic use' relates to `use_case`. It does not clarify `source_ref`, `independent`, `witness_ref`, `provenance_type`, or the exact semantics of 'standing'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'split claims by standing and evaluate explicit promotion requests', identifying both the operation and the resource. It distinguishes itself from siblings like athena_claim_promote or athena_promotion_evaluate by focusing on epistemic split, though the acronym 'ESCPF' and term 'standing' are unexplained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you need to split claims by standing or evaluate explicit promotion requests. However, no explicit when-not-to-use guidance or alternative tool references are provided, even though siblings like athena_claim_promote and athena_promotion_evaluate exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full transparency burden. It discloses that the tool is observation-only and lacks semantic authority, which is a useful behavioral trait. However, it does not mention side effects of the 'Update' operation, any required permissions, reversibility, or what it returns, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action. Every clause contributes meaning: the update action, the purpose, and the scope limitation. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, a nested object, no output schema, and no annotations, the description is too brief to be operationally complete. It fails to explain return values, parameter details, edge cases, or how the update modifies the context distribution. The description does not cover the tool's full contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, and the description adds minimal parameter insight. It mentions 'regime' and implies 'features' through the concept of an empirical context distribution, but it does not explain the structure of the features object, the meaning of scope, or parameter relationships. This is insufficient given low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the specific action (Update) and resource (empirical context distribution), and clarifies the purpose is for detecting distribution shift in a regime. It also adds the qualifier 'Observations only; no semantic authority,' which distinguishes its scope from other tools, but it does not explicitly differentiate from sibling tools like athena_ood_score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what the tool does, but it does not explicitly state when to use it versus alternatives or provide exclusions. The phrase 'Observations only; no semantic authority' gives some guidance on what it is not for, but this is implicit rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the computation is 'exact' and mentions optional robust/direction modes, but it does not state side effects, return format, or error behavior. This is limited but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that conveys the core function and two optional parameters. No filler or redundancy, and it is front-loaded with the main verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested arrays, multiple optional parameters, no output schema or annotations), the description leaves critical details unresolved: how candidates are structured, what epsilon means, how directions is specified, and what the frontier output looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), so the description must compensate. It hints at candidates, robust, and directions via 'interval-robust dominance' and 'min/max metric directions', but it does not explain the epsilon parameter or the expected structure of candidates/directions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes the exact non-dominated frontier for a candidate set, with optional interval-robust dominance and direction handling. It is specific and distinct from sibling tools, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other athena_* optimization or geometry tools. The description implies use for Pareto frontier computation but gives no exclusions, prerequisites, or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds the useful trait 'Deterministically' and mentions the 'configured Git brain', implying reproducibility and a configuration prerequisite. However, it does not disclose potential side effects, whether it is a read-only operation, or any requirements for the Git brain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no fluff. It front-loads the key verb 'compile' and includes only relevant details, making it easy to read and process.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of 3 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain what output is produced, what the parameters do, or any usage context beyond the one-line summary. This is insufficient for safe and effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the parameters (task, profile, include_text). It references 'selected modules' but does not map these to the schema. The agent cannot infer what each parameter controls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action ('Deterministically compile') and its specific inputs (policy, selected modules, scoped overlays) from the 'configured Git brain'. This is specific and distinguishes it from other compile-like tools (e.g., field_compile, gap_compile) and prompt-related siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like athena_prompt_hydrate or athena_prompt_sync. The description implies it is for compiling a prompt from Git brain, but does not state conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden; it clearly states 'SIMULATE_ONLY', which implies non-destructive evaluation. However, it does not disclose return format, error behavior, or whether the evaluation modifies state, leaving the agent with only partial behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The two-sentence description is compact with no wasted words, but the first sentence is dense and jargon-heavy, making it less scannable. The standalone 'SIMULATE_ONLY.' adds useful emphasis but could be integrated more cleanly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with no output schema and no annotations, this description gives only the core concept and leaves major gaps: parameter semantics, return format, and relationship to other simulation tools. An agent would need additional information to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description only implicitly references 'actions' as finite action sequences and 'cvar_alpha' via lower-tail CVaR. Parameters like ridge, discount, risk_aversion, scenario_sigma, initial_context, and trajectories are left unexplained, providing insufficient semantic grounding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific operation ('Evaluate') with a clear object: caller-supplied finite action sequences on three-branch moment scenario trees, and adds expected return and lower-tail CVaR metrics. It is distinct from generic simulation tools due to the scenario-tree and CVaR focus, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'caller-supplied finite action sequences' and 'SIMULATE_ONLY' imply the tool is for offline evaluation of sequences, providing some contextual guidance. However, there is no explicit 'when to use versus X' guidance, no prerequisites, and no named alternatives, so the usage boundaries remain implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It reveals algorithmic traits (bounded beam-search, finite-horizon) and the limitation of no global optimality, but does not state whether the tool mutates state, requires authorization, or what it returns. This is a significant gap in understanding the tool's side effects and output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that front-loads the algorithm type and scope, followed by constraints and a limitation. Every word contributes value, with no padding or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, nested objects, no output schema, and no annotations, the description is under-specified. It omits parameter semantics, return behavior, side effects, and usage guidance, making it inadequate for an agent to confidently select and invoke the tool without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate, but it only loosely maps to parameters (e.g., 'task dependencies' to tasks, 'worker capacity' to workers, 'resource budgets' to budget, 'finite-horizon' to horizon, 'beam-search' to beam_width). It fails to explain parameter formats, defaults, or relationships for the 7 parameters, leaving most semantics unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a 'bounded beam-search finite-horizon scheduler' over task dependencies, worker capacity, and resource budgets, conveying its core function. However, it does not explicitly distinguish it from sibling scheduling tools like athena_budget_schedule or athena_collective_plan, relying mainly on algorithmic details rather than comparative differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finite-horizon scheduling with dependencies and resource constraints, and the caveat 'does not claim global optimality' provides a limitation. Yet it offers no explicit when-to-use or when-not-to-use guidance, nor does it reference alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'with provenance event' but does not disclose side effects, required permissions, idempotency, failure behavior, or return values. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. It is concise and front-loaded with the primary action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters, no annotations, no output schema, and no parameter descriptions. The description is too minimal to provide complete context, leaving the agent without enough information about prerequisites, side effects, or return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the five parameters. While 'typed' hints that `relation` is the edge type and 'provenance event' might relate to `actor` or `attrs`, the description does not compensate for the complete lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add one typed JSPACE edge with provenance event' clearly specifies the action (add), the resource (typed JSPACE edge), and a distinguishing detail (provenance event). It differentiates from siblings like athena_add_hyperedge by indicating an edge rather than a hyperedge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as athena_add_hyperedge or other add-related tools. The description does not mention any conditions, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only notes that provenance is included. It does not disclose mutation side effects, required permissions, idempotency, or any failure behavior. The verb 'Add' implies a write operation, but the behavioral detail is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action and key distinguishing feature (n-way) without any fluff. It is appropriately sized and every word adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—4 parameters, a nested attrs object, and no output schema—the description is insufficient. It does not explain the structure of members, allowed relation types, or how provenance is captured, leaving significant gaps for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the parameters such as relation, members, actor, or attrs. The terms 'typed' and 'n-way' are general but do not explain how to use the schema fields, leaving the agent without guidance for constructing valid calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: adding a typed JSPACE hyperedge or n-way semantic relation, with provenance. The verb 'Add' and resource 'hyperedge' are specific, and the mention of 'n-way' distinguishes it from simple edge tools like athena_add_edge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a multi-way relation is needed, but it does not explicitly state when to use this tool versus alternatives such as athena_add_edge. There is no mention of exclusions or preferred contexts, only the implicit indication from 'n-way semantic relation'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal that execution happens in a 'restricted repository-owned subprocess' and that arbitrary shell/command refs are rejected, which is valuable safety context. However, it omits side effects, recording behavior (despite the record_outcome parameter), and return values, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly-worded sentence that leads with the primary action and quickly covers key constraints. Every phrase earns its place, with no redundancy or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a clear purpose, the description omits details on all parameters, expected output, and side effects. With no output schema and no annotations, these gaps prevent an agent from understanding the full invocation contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameter meanings. It only implicitly associates antibody_id with the witnesses, but fails to describe actor, max_refs, timeout_s, or record_outcome. This is insufficient for an agent to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Execute') with a clear resource ('stored failure-antibody unittest witnesses') and adds environmental context ('in a restricted repository-owned subprocess') plus a constraint ('no arbitrary shell/command refs are accepted'). This clearly differentiates it from related sibling tools like athena_antibody_evolve or athena_antibody_select.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state when to use this tool versus alternatives or provide usage context beyond its core function. The note that no arbitrary shell/command refs are accepted is a limitation, but it does not offer explicit guidance on when to choose this tool or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It discloses that the tool processes 'one explicit observed reward' and 'retains pre-update prediction for calibration', which are meaningful. However, it omits details about side effects, required permissions, state mutability, or error conditions, leaving a moderate transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence with no filler. It front-loads the primary action and includes a secondary behavioral note. Its brevity is admirable, though it sacrifices some completeness for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, no output schema, and no annotations, this description is far too sparse. It does not clarify return values, parameter formatting, error semantics, or prerequisite conditions. The agent would struggle to invoke this tool correctly for complex use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description is the only source of parameter meaning. It explicitly references only 'reward' and vaguely implies 'features' via 'contextual state'. The other seven parameters (ridge, scope, actor, regime, arm_id, weight, target_coverage) are unexplained, leaving the agent without sufficient semantic guidance for parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the core action: 'Update full-covariance Bayesian contextual state' from 'one explicit observed reward'. This specifies both the verb ('Update') and the precise resource ('full-covariance Bayesian contextual state'), which distinguishes it from sibling observe/predict tools. The addition of 'retains pre-update prediction for calibration' further clarifies its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: after a single reward observation, update the Bayesian state, and the retained prediction is useful for calibration. However, it does not explicitly state when to use this tool versus alternatives like athena_bandit_observe or athena_elder_observe, nor does it provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses a key behavior: 'Unknown IDs HOLD rather than fabricating a classification.' This adds useful safety context. However, it doesn't disclose side effects, permissions, or what 'compile' does to system state, which is a gap for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient: two sentences, with the core action front-loaded and a behavioral guarantee second. It avoids fluff, though the first sentence is a dense run-on with heavily hyphenated jargon that could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema and annotations, so the description should explain what the tool returns or what 'compile' produces. It describes the contract contents but never states the return value, side effects, or failure modes. The 'HOLD' behavior is mentioned, but it's unclear what that means in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It implicitly ties the parameter to the BNMK machine identity ('Compile one known BNMK machine') and hints at unknown ID handling. Yet it never names 'machine_id' or describes its format, leaving the agent to infer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Compile one known BNMK machine') and the output artifact ('source-backed 4D/12D/KC144 contract'), distinguishing it from sibling compile tools by resource. However, heavy jargon like 'BNMK', '4D/12D/KC144' and 'state cycle and row associations' makes it less accessible to a general agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. It doesn't mention prerequisites, context, or sister tools. The only behavioral note about unknown IDs is not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only offers a conceptual comparison ('Smith-chart-inspired compatibility proxy; not physical electrical impedance') and does not address side effects, return format, whether the operation is read-only, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences with no filler. The first sentence delivers the core function, and the second clarifies the conceptual model. The 'not physical electrical impedance' clarification is useful but could be placed more efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two nested-object parameters and no output schema or annotations, the description is under-specified. It lacks information about return values, how to interpret the score, how to construct valid profiles, and any usage context. The agent would need to cross-reference sibling tools or rely on external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists the six profile dimensions (rate, latency, error tolerance, statefulness, reversibility, coupling) which map directly to schema properties, but it does not explain the meaning of 'producer/consumer' roles or how the scoring scale integrates with the numeric range in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Score a normalized producer/consumer interface profile over rate, latency, error tolerance, statefulness, reversibility and coupling.' This is a specific verb-resource combination that distinguishes it from sibling tools, further clarified by the 'Smith-chart-inspired compatibility proxy' metaphor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention exclusions, prerequisites, or relationships to sibling tools (e.g., other bionano tools), leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It does disclose that the tool does not grant execution authority or causal equivalence, which is a useful negative behavioral trait. However, it does not mention side effects, required permissions, or what the output looks like, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each serving a distinct purpose: the first defines the action, the second clarifies a limitation. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters with 0% schema coverage and no output schema, yet the description only provides a high-level purpose and a caution. It doesn't explain what the tool returns, how to choose parameters, or when to invoke it, making it insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the parameters (target, machine_id, constraints) or their meanings. It fails to compensate for the schema's lack of descriptions, so the agent gets no help understanding what to pass.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Map' and the resource: a 'source-backed biological mechanism' into a 'target ATHENA problem' as 'COMPUTATIONAL_ANALOGY'. This distinguishes it from sibling bionano tools by highlighting the analogy output, though it doesn't name specific siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a computational analogy from a biological mechanism, but doesn't explicitly state when to use it over alternatives. The caveat 'never grants execution authority or causal equivalence' provides a usage caution but not a clear decision rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided and no output schema, the description carries the full burden of behavioral disclosure. It says the tool 'emits corrective actions', implying it produces output, but it does not state whether the operation is read-only, has side effects, or depends on any thresholds. There is no mention of what the output format looks like or how the corrective actions are derived. This lack of transparency is a significant gap for a tool that takes a composite metrics object.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs a comprehensive list of evaluated metrics. Every part of the sentence contributes to the purpose, with no fluff or repetition. However, the long list makes it a bit dense and could have been structured with bullet points for readability, but it remains efficient and front-loaded with the core action ('Evaluate... emit...').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a nested metrics object with 10 fields), the absence of an output schema, and no annotations, this description is incomplete. It does not explain the return value (the corrective actions), their format, how they should be applied, or what 'collective homeostasis' means in practice. Agents would lack critical context needed to interpret results or proceed after invocation, so this is a 2.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines a single 'metrics' object with ten properties, but schema description coverage is 0%. The description compensates partially by listing named metric categories (saturation, duplication, latency, error, staleness, contagion, reserve depletion, weak evidence, bridge overhead, coordination drag) that map to the schema properties. However, it does not explain the meaning of each metric in detail or how to interpret their values beyond what the schema's min/max constraints already provide. Thus, it adds some value but not enough to fully cover the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates collective homeostasis and emits corrective actions, listing specific metric domains (saturation, duplication, latency, etc.). This is a specific verb+resource combination that distinguishes it from siblings like athena_collective_evaluate or athena_collective_plan by emphasizing the 'corrective action' output. However, it does not explicitly name a sibling alternative, so it falls 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case: when you want to assess collective health and receive actionable corrective suggestions. However, it provides no explicit guidance on when to prefer this tool over similar siblings (e.g., athena_collective_evaluate, athena_collective_plan) or when not to use it. The usage context is implied but not articulated with exclusions or alternatives, so it garners a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. The verb 'Read' indicates a non-mutating operation, and the description specifies the returned data (mean/covariance and observation count). However, it does not disclose error behavior (e.g., missing context_key), permissions, or whether the observation count is included in the covariance structure. It provides minimal but non-contradictory transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that leads with the verb and object. Every word contributes to the core meaning. It is appropriately sized for a simple read operation without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no output schema, and no annotations, so the description must cover both input semantics and return structure. It partially covers the return (mean/covariance/observation count) but omits the meaning of context_key and the exact format of the output. Given the large sibling toolset and the need for precise invocation, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, context_key, with no description (0% coverage). The description fails to explain what context_key represents or how to obtain it. An agent cannot determine what value to pass, making the tool difficult to invoke correctly. The description adds zero semantic value for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and resource ('Gaussian linear belief'), clearly stating what is read: mean/covariance and observation count. This distinguishes it from sibling tools like 'athena_gaussian_belief_observe' (which likely updates) and 'athena_gaussian_belief_register' (which creates), as well as the more generic 'athena_belief_state'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor any exclusions or prerequisites. It simply states what the tool does, leaving the agent to infer context from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does convey that the operation is hypothetical and design-only, which signals non-destructive intent. However, it does not explain what the returned decision value looks like, whether any state changes are persisted, or what side effects might occur beyond the implied computation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that front-loads the core purpose ('Estimate decision value') and appends a useful design-only caveat. There is no wasted filler, and every phrase contributes something meaningful to the tool's identity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters and no output schema, so the description must carry substantial contextual weight, but it remains only one sentence. It does not explain what 'decision value' means in this context, what outputs to expect, how actions/experiments relate to the EVSI computation, or how this tool fits alongside sibling EVSI/GP tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds almost no parameter-level meaning. The phrase 'candidate GP measurements' loosely maps to the 'candidates' parameter, but required parameters like context_key, actions, and experiments, as well as cost_weight, risk_weight, samples, and seed, remain unexplained in both the schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Estimate decision value') and a clear resource ('candidate GP measurements'), and it explains the distinctive mechanism ('updating both finite-grid kernel weights and within-kernel posterior action means hypothetically'). This effectively distinguishes it from generic EVSI tools like athena_decision_evsi and even athena_gp_decision_evsi by highlighting the BMA and hypothetical update details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as athena_decision_evsi, athena_gp_decision_evsi, or athena_gp_bma_predict. The 'DESIGN_ONLY' note hints at a planning context but does not state usage conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action (append) but omits important behavioral details: whether it mutates persistent state, what 'bounded' means (e.g., what happens when the bound is reached), whether it is idempotent, what error conditions apply, and what, if anything, is returned. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and resource. Every word contributes, with no redundancy, filler, or irrelevant detail. It is appropriately concise for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested object, no annotations, no output schema, 0% schema coverage), the one-sentence description is highly incomplete. It lacks context about parameter formats, dataset bounds, return values, and prerequisites, preventing an agent from confidently invoking the tool without further information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only clarifies the 'target' parameter via 'actual observed target'. The semantics of 'context_key', 'features' (a nested object), 'actor', and 'evidence_ref' are left unexplained, forcing the agent to guess their roles. This is insufficient for five parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Append' and identifies a unique resource: the 'bounded fixed-kernel GP dataset'. This clearly distinguishes it from sibling GP tools like athena_gp_predict (prediction) and athena_gp_hyperfit (hyperparameter fitting), and from generic observe tools. The phrase 'actual observed target' adds precision about the kind of data being appended.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not state prerequisites (e.g., that a GP dataset must already exist), when not to use it, or how it differs from related tools like athena_transition_observe or athena_gp_register. The usage context is only implied by the action of appending.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It does state it is a read operation and that it applies specifically to fixed-kernel GPs, which is useful. However, it does not disclose what happens if the context_key is invalid or if the GP is not fixed-kernel, nor does it describe the return format beyond naming the two data items. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose without wasted words. Every word contributes to the meaning, making it appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one required parameter with no semantics, no output schema, and no annotations, the description is too thin to fully enable correct invocation. It omits an explanation of context_key and does not describe the output structure or error behavior, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for context_key beyond type 'string', and schema description coverage is 0%. The description does not mention context_key at all, so an agent has no way to know what value to supply or what the key refers to. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as reading fixed-kernel GP hyperparameters and observed-point count, with a specific verb ('Read') and resource. It distinguishes from sibling GP tools like athena_gp_hyperfit (fitting) and athena_gp_predict (prediction) by focusing on state inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Among the many GP-related siblings, it does not mention that this is for inspecting current state, nor does it exclude cases like fitting or predicting. No context is given for when this read is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden of behavioral disclosure. It mentions directedness and typed relations but does not indicate whether the operation is read-only, what happens when no path exists, or any other side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence of 16 words, front-loaded with the verb and no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 fails to specify the return format (path, length, or both), the meaning of max_depth, or behavior in edge cases, leaving the tool incomplete for a 4-parameter operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate fully. It implies src/dst are nodes and relations are typed relations, but it omits max_depth entirely and does not clarify expected node/relation formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with the specific verb 'Compute' and names the resource as a 'shortest directed JSPACE path', clearly distinguishing from sibling graph tools like athena_dense_navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when this tool should be used versus alternatives. The description simply states the operation without mentioning any prerequisites, exclusions, or comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must stand alone. It states the operation is a read, which implies non-destructive behavior, and adds a sync prerequisite. But it does not explain what happens if the sync is not fresh, nor describe the response structure or any potential 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action ('Read'), and contains no filler. It is efficient, though it omits critical details that could be communicated with slightly more structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters and no output schema or annotations, the description is under-specified. It gives the basic purpose and a timing condition but leaves parameter semantics, return values, and error conditions completely unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has three parameters (remote, quest_id, shared_remote_mode) with 0% description coverage. The description does not mention any of them or their meanings, so the agent has no guidance on how to populate them, especially the enum for shared_remote_mode.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a concrete read operation ('Read one Impossible Challenge and its completions') and includes a precondition ('after a fresh shared Message Board sync'). This distinguishes it from sibling tools like athena_impossible_open or athena_impossible_complete, though the meaning of 'Impossible Challenge' and 'completions' is not elaborated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states a context for use ('after a fresh shared Message Board sync'), which tells the agent when to call it. However, it does not mention alternatives or explicit exclusion of other tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits on its own. It only states the primary effect (persist and assign coordinates) but does not mention side effects, permissions, idempotency, overwrite behavior, or error cases. This leaves significant behavioral ambiguity for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the primary action and includes specific detail about the coordinate assignment. No wasted words; every part contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 params, no output schema, no annotations), the description is too sparse. It does not explain all parameters, provide usage context, or describe return values. For an agent to invoke it correctly, additional information would be needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It indirectly clarifies 'oid' and 'expected_vid' via the coordinate system, but leaves 'text', 'actor', 'carrier', and 'native_locator' unexplained. This is insufficient for a 6-parameter tool with no other parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Persist a text manifestation') and a distinctive outcome ('assign exact KC144/OID/VID/MID/paragraph/sentence/token/character coordinates to every non-whitespace lexeme'). This distinguishes it from generic persist tools like athena_register or athena_hydrate by emphasizing the coordinate-assignment function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. It does not mention any prerequisites, exclusions, or situations where another sibling tool would be more appropriate. The description simply states what the tool does, leaving usage decisions to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses key behavioral traits: simulation grants no execution authority, and missing boundary/phase or declared hazardous classes cause a HOLD. These are valuable safety and control-flow details, though return behavior and side effects are not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the action and key constraints. However, the unexplained 'RSM:' prefix adds noise without immediate value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, nested objects, no output schema, and no annotations, this description is far from complete. It fails to explain the B->Theta->Pi workflow, the semantics of required parameters, or what the simulation returns, leaving an agent unable to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides minimal parameter insight. It hints at boundary and phase being relevant (by mentioning 'missing boundary/phase') and hazardous classes map to risk_class, but it does not explain mode, steps, witness, or the structure of boundary and phase objects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool simulates a B->Theta->Pi workflow gating process, providing a specific verb (simulate) and resource. However, the jargon 'B->Theta->Pi' is unexplained, and it does not differentiate from sibling MCP tools like athena_mck_model_bridge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The simulation nature implies safe testing, but the description does not state prerequisites, exclusions, or when a different tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It explains the two-step process (identify frontier, then choose candidate) and the constraint that it is only for experiment selection. Yet it does not disclose whether the operation is read-only, what side effects or mutations occur, what the return value is, or any permissions needed. This is a moderate gap given the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loads the main purpose. The first sentence clearly states the action, and the second adds a strong scope constraint. It is concise, though 'EXPERIMENT_SELECTION_ONLY' is partly redundant with 'choose ... for experimentation' and adds a tone that could be clearer without the capitalization.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, a nested object schema, and no output schema, the description is too sparse. It doesn't explain what inputs are needed, how to structure candidates, what 'interval-possible' means, or what the output looks like. The agent cannot reliably invoke this tool without additional schema descriptions or examples, so completeness is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the three parameters (candidates, directions, exploration_weight). The agent gets no guidance on what the candidates array should contain, what directions means, or how exploration_weight behaves. The description's mention of 'Pareto frontier' and 'uncertainty-rich' is too vague to compensate for the complete lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it identifies an interval-possible Pareto frontier and selects an uncertainty-rich candidate for experimentation. The phrase 'EXPERIMENT_SELECTION_ONLY' reinforces the selection-specific scope, which helps differentiate it from tools that compute frontiers or perform other bandit operations. However, the term 'interval-possible' is jargon and the description doesn't explicitly contrast with sibling tools like athena_pareto_frontier or athena_bandit_select.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly scopes usage with 'EXPERIMENT_SELECTION_ONLY', making it clear this tool is for experiment selection rather than general Pareto or bandit analysis. It states when to use it (for selecting a frontier candidate) and implicitly when not to (anything outside experiment selection). It does not, however, name alternative tools for other tasks, which would make the guidance fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only mentions the methodology (learned diffusion coefficients) and does not disclose side effects, state mutations, return values, permissions, or prerequisites, which is insufficient for a tool with this complexity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the core action and differentiator, though it is arguably too sparse for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, nested objects, no output schema, no annotations, and 0% schema description coverage, a one-sentence description is drastically incomplete. An agent would lack essential context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implicitly references 'coordinates' and 'multiscale' (source_scale) but leaves deposit_gain, evaporation_rate, observations, age, and actor completely unexplained, providing minimal help in understanding parameter purposes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('reinforce') and resource ('declared multiscale coordinates'), and explicitly differentiates from siblings by noting 'learned diffusion coefficients rather than fixed scale attenuation.' This clearly distinguishes it from related pheromone reinforce tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'rather than fixed scale attenuation' clause implies when to use this tool (when adaptive learning is desired), but it does not explicitly name alternatives, exclusions, or provide concrete when-to-use/when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It clearly states 'Read', indicating a non-mutating operation, and adds 'durable' to suggest persistence. However, it does not disclose return shape, ordering, or effects of limit/min_score, leaving important behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with the verb 'Read' front-loaded; no filler words. It is efficient and scannable, though the dense jargon ('durable stigmergic priority field') is not elaborated, which slightly reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters, no output schema, and no annotations, this description is under-specified. It does not define how limit, min_score, and route_key interact, nor what the response contains, making it insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only loosely maps 'one route' to route_key and 'highest-priority routes' to limit/min_score without explaining the parameters' exact meanings. No parameter names or value semantics are provided, so it does not compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Read' and names the resource as 'durable stigmergic priority field', with scope ('one route or the highest-priority routes'). It distinguishes from sibling write tools like athena_pheromone_reinforce by implying a read operation, though other 'field' siblings are not clearly differentiated. Domain jargon limits universal clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: querying a single route or top-priority routes. It does not provide explicit when-to-use/when-not-to-use guidance or name alternatives. Sibling tools such as athena_pheromone_reinforce are implicitly excluded by the word 'Read', but no direction is given for choosing among similar field-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses behavioral details: verification is independent, uses an internally produced trusted verifier receipt, and the caller lacks control over several configuration aspects. However, it does not mention side effects, permissions, failure behavior, or return format. It is more transparent than a simple 'Verify promotion' but still leaves significant unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—two sentences. It front-loads the main purpose ('Independently verify...') and the second sentence adds useful constraints. However, it uses unexplained jargon (PROMOTION.2, trusted verifier receipt) that forces the reader to infer meaning, which slightly reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 params, no output schema, and no annotations, the description is insufficient. It does not explain what the tool returns, what persist or actor affect, or what timeout_s is for. The internal steps of verification and receipt production are mentioned but not elaborated into a complete picture for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all four parameters. It only elaborates on git_head ('target Git head'); actor, persist, and timeout_s are not explained at all. Given 4 params and zero schema descriptions, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs two actions: independently verifying a target Git head against host-configured GitHub settings and then evaluating PROMOTION.2 with a trusted verifier receipt. It is specific about the resource (Git head, GitHub repository/check-suite) and distinct from generic promotion tools, though it does not explicitly name sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this when you need independent verification of a Git head against host-configured GitHub settings. It lists constraints (caller cannot choose repository, API host, etc.) but does not provide explicit when-to-use vs. alternatives or when-not-to-use guidance. No sibling tool is mentioned as an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses a key behavioral trait—that the tool does not activate or promote—but doesn't explain side effects, prerequisites, or how it interacts with version control (despite fields like rollback and expected_git_head). This is moderate disclosure but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loads the core action, but the unexplained 'CAS' prefix and the lack of any parameter context make it slightly less efficient than it could be. It's still concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters (7 required), no output schema, and no annotations, a one-line description is severely inadequate. It doesn't explain what the proposal event is, how to populate required parameters, what happens on success, or what 'versioned' means in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about any of the 12 parameters. It fails to explain the meaning or usage of required fields like module_id, defect, falsifier, rollback, or expected_git_head, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a versioned prompt candidate plus proposal event, using a specific verb ('write') and resource. It also distinguishes from siblings by explicitly noting it never activates or promotes itself, differentiating it from tools like athena_prompt_activate and athena_prompt_promote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the proposal never activates or promotes itself, providing a clear exclusion. However, it doesn't explicitly name alternative tools or provide context on when to choose this tool, leaving the usage guidelines implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses what the tool exposes (predictive covariance, parameter-information leverage) but does not state whether this is a read-only operation, whether it modifies or persists any state, or what assumptions or side effects accompany fitting. Without this context, the agent cannot anticipate mutations, permissions, or data requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that wastes no words. It front-loads the main action ('Fit') and packs in the key outputs and input type. While the terminology is advanced, the precision and efficiency are excellent for a technical tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex statistical tool with 4 parameters, no output schema, and no annotations. The description provides only the general action and two output concepts, omitting crucial details about what the 'context' object should contain, the meaning of 'action_id', the effect of 'max_features', and the exact structure of the returned predictive covariance and leverage information. Given the tool's complexity and the absence of structured metadata, the description is inadequate for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to compensate. It mentions 'ridge' in the method name but does not explain the 'ridge' parameter, nor does it clarify the roles of 'context', 'action_id', or 'max_features'. The phrase 'observed before/after action rows' hints at the context object, but it is too vague to map to the schema, leaving all four parameters under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fit' and a specific resource 'ridge state-dependent multivariate transition-delta regression', clearly distinguishing it from sibling tools like athena_transition_predict or athena_transition_observe. It also mentions the derived outputs 'predictive covariance' and 'parameter-information leverage', making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only implies usage by saying 'from observed before/after action rows', but provides no explicit guidance on when to use this tool versus alternatives like athena_transition_distribution or athena_causal_* tools. There are no exclusions, prerequisites, or mentions of situations where this model is preferred, which is especially problematic given many closely related transition/regression tools exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It states that missing surfaces or probe failures return FAIL, which is useful, but it does not disclose whether the operation is read-only, has side effects, or what the full return format is. This is partial transparency, not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence defines the action and target, the second clarifies the failure condition. It is appropriately sized and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single optional parameter and no output schema, increasing the descriptive burden. The description covers the purpose and a key failure behavior, but it does not explain what the output looks like (beyond FAIL), how run_probes affects the audit, or what the 'contract' and 'certificate' entail. It is adequate for a domain expert but incomplete for a general AI agent relying solely on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the 'run_probes' parameter. The term 'probes' appears in the description, offering an indirect clue, but the agent is left without explicit documentation of what the boolean does, defaults, or its effect on the audit. The description fails to compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool audits the promoted unified runtime against a specific contract and certificate, with a clear outcome (FAIL on missing surfaces or organ/probe failures). It is specific in verb and resource but does not explicitly differentiate from sibling tools, so it earns a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case (auditing after promotion) but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions. With a large sibling list, this lack of direction leaves the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It does disclose a key behavioral rule: worker-allocation metrics are never invented, and candidates without explicit collective_metrics are marked UNMEASURED and not allocation-ready. This is valuable, but it does not mention potential side effects of the 'persist' parameter, whether the tool writes to storage, or return behavior, leaving significant transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences that both earn their place. The first clearly states the core purpose, and the second adds a crucial caveat about metric fidelity. There is no redundant wording or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should clarify what the translation yields (e.g., whether it returns a list, a status, or creates records). It also does not explain the meaning of required parameters like 'run_id' or the side effect of 'persist'. The transformation target is named, but the result format and side effects remain ambiguous, making the description insufficient for a tool with these parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for missing parameter documentation. It does not explain 'actor', 'run_id', or 'persist'. The word 'persisted' only implicitly hints at run_id, but no explicit mapping is provided, leaving all three parameters semantically opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: translating a persisted AORRUN successor frontier into Collective task identities/capability requirements, using a specific verb ('translate') and a specific resource. However, it does not explicitly distinguish this from similar transport tools like athena_transport_bridge_to_collective, so it doesn't earn the top score for sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied by the description: use this when you have a persisted AORRUN successor frontier and need Collective task identities/capability requirements. However, there is no explicit 'when to use' statement, no exclusions, and no mention of alternative tools, so it only meets the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does add context that the returned object includes a 'frozen' input/output boundary packet and digest, which suggests an immutable snapshot. However, it does not mention error behavior (e.g., missing run_id), return format, or whether any other data is included, leaving some transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose without any fluff or repetition. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only one parameter and no output schema, so the description covers the main purpose. However, it lacks mention of error cases, the response structure, or alternatives like recent/replay, which would make it more complete given the large sibling set and absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (run_id) with 0% description coverage. The description does not elaborate on what run_id is or how it should be formatted beyond the schema's minLength. The name 'run_id' is self-explanatory, but the description adds no additional semantic meaning, so it fails to compensate for the low schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and the resource ('one persisted TRANSPORTRUN'), with additional specifics about what is included (frozen input/output boundary packet and digest). However, it does not explicitly distinguish itself from sibling tools like athena_transport_recent or athena_transport_replay, though the singular 'one' and reference by run_id imply a direct fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as athena_transport_recent or athena_transport_replay. The description implies you should use it when you have a specific run_id, but it does not state exclusions or mention other available tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the entire burden of behavioral disclosure. It implies a read-only list operation but fails to explain ordering, default time window, pagination, or any side effects. The minimal phrasing gives no insight into expected behavior beyond the literal action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is front-loaded with the verb and resource, and every word contributes to the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description should clarify what a 'transport receipt' is, what 'recent' means, and what the agent can expect in the response. The description is too sparse to support reliable invocation, especially given the large set of similar transport and *_recent sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines a single 'limit' integer with min and max constraints but no description. The description does not mention the parameter or its effect on results. The name 'limit' is self-explanatory to some degree, but the description adds no semantic meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recent AOR×Collective transport receipts, using a specific verb and resource. This distinguishes it from sibling tools like athena_transport_get (which likely fetches a single transport) and athena_transport_replay (which replays a transport).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as athena_transport_get or other *_recent tools. The description does not mention any context, prerequisites, or exclusions, leaving the agent without explicit selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It indicates a non-mutating read operation via 'Return' and adds 'Diagnostic only' as a behavioral constraint. However, it does not disclose potential side effects, prerequisites, or operational characteristics such as cost or model dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise, front-loaded sentence that clearly states the action and output. 'Diagnostic only' adds a useful qualifier without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has seven parameters, no output schema, and no annotations, requiring the description to compensate. Although the description lists the output components, it omits all parameter guidance and usage context, making the description insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter semantics. None of the seven parameters (features, regime, arm_id, ridge, scope, ood_gain, target_coverage) are explained, leaving the agent without the information needed to construct a valid invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a decomposition into specified uncertainty components and notes it is diagnostic only. It names the specific resource ('model-conditional proxy decomposition') and lists the components, but it does not explicitly differentiate from sibling tools like athena_uncertainty_calibrate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Diagnostic only' implies the intended use context but does not provide explicit when-to-use guidance or mention alternatives. No exclusions or alternative tool references are present, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description bears full responsibility for behavioral disclosure. It states that data is persisted, implying a write side effect, but it does not disclose return behavior, idempotency, overwrite semantics, authorization needs, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with the verb front-loaded. It avoids redundancy and wastes no words, though the dense jargon ('normalized budget pressure') slightly reduces immediate readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, nested objects, no annotations, and no output schema, the tool requires richer guidance. The description covers only some data concepts and omits usage, return expectations, and behavior, making it incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds valuable semantics by mapping 'resources' to per-worker resource use, 'budget' to normalized budget pressure, and 'useful_output' to useful-output efficiency. However, it leaves actor, scope, and task_id unaccounted for, leaving clear gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'Persist' and identifies the exact resource/scope: measured per-worker resource use, normalized budget pressure, and useful-output efficiency. This clearly differentiates it from sibling observe/record tools by focusing on worker-cost data for scheduling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives like athena_budget_record or other observe tools. The phrase 'for future scheduling' provides only an implied purpose, not usage context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 a task-only call observes coordination without side effects, while explicit work_key/targets/claim mode or coordination_mode=AUTO may establish/reuse presence, and duplicate claimed work holds. This gives meaningful behavioral side-effect information beyond the schema. It doesn't cover all side effects (e.g., permissions, return state) but is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with semicolons, packing a lot of information into a compact form. It's not overly long, but the structure is difficult to parse and could benefit from a list or clearer separation of concepts. It earns a middle score for efficiency without good readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 18 parameters, no annotations, and no output schema, so the description must explain a lot. It addresses the bootstrap and coordination boundary but leaves the meaning of many parameters, the return value, and lifecycle behavior unspecified. The description is insufficient for an agent to confidently invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description only clarifies work_key, targets, and coordination_mode. Most of the 18 parameters (task, fetch, remote, profile, issue_repo, source_ref, issue_limit, lease_seconds, replication_reason, shared_remote_mode, continuation_loop_id, coordination_details, coordination_claim_mode, continuation_shared_remote_mode) are left with no explanation in either schema or description. The description partially compensates but is far from adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Cold-start AGENT_BOOT_V1 with an automatic Message Board handshake', which names a specific action and resource. However, it doesn't explicitly distinguish from siblings like athena_agent_refresh, and the jargon 'AGENT_BOOT_V1' is not defined. The rest of the description focuses on coordination boundaries, which clarifies intent but not purpose in ordinary terms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the difference between a 'task-only tool call' (observes without claiming work) and explicit coordination parameters that 'cross the start-work boundary', giving a clear conditional usage hint. However, it never names alternative tools or states when to prefer another tool, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'Read' indicates a read-only operation, which is a key behavioral trait given that no annotations are provided. However, the description does not disclose additional behavioral details such as error behavior, required permissions, or what the returned state looks like. It carries some of the burden but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that leads with the verb and includes only necessary information. Every phrase adds value: the action, the resource, the scope, and the optional parameter. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, the description should explain expected return values or state semantics. It does not describe what 'branch lifecycle state' includes, how the state is represented, or how 'metric basis' affects the result. This is insufficient for an agent to fully understand the tool's output and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for parameter meaning. It does clarify that the tool operates on 'one branch' (branch_id) and optionally 'one metric basis' (basis_id), providing basic semantic roles. However, it does not explain what a 'metric basis' is, what valid values exist, or the parameter formats, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and the resource ('branch lifecycle state'), and indicates the scope ('for one branch'). It is specific enough to understand the primary function, but it does not explicitly distinguish itself from sibling tools such as branch_observe or branch_list, which could potentially serve similar purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention specific scenarios, prerequisites, or contrast with sibling tools. The only implied usage is that it reads branch state, but without further context, an agent cannot decide between this and related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'exact only under declared finite-model assumptions,' which is a caveat about validity, but it does not disclose how the tool behaves if those assumptions are violated, what limits (like exact_limit) do, or what output to expect. This is insufficient for a complex selection/optimization tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that is not wasteful and leads with the main action ('Select a value-maximizing small finite candidate subset'). However, its density sacrifices readability, and it omits necessary context, so it is not the ideal concise description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—4 parameters, nested objects, no annotations, and no output schema—the description is incomplete. It provides no parameter semantics, no usage guidance, and minimal behavioral context. The 'exact only under declared finite-model assumptions' caveat is too vague to fully prepare an agent for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (candidates, budgets, alpha, exact_limit). The phrase 'independent-Gaussian one-sided resource chance constraints' hints at the meaning of budgets and alpha, but it is too abstract to help an agent construct valid arguments, and exact_limit is not mentioned at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'selects a value-maximizing small finite candidate subset' under specific independent-Gaussian chance constraints, which distinguishes it from sibling tools like athena_dro_resource_select by naming the exact optimization model and objective. The verb 'select' and the resource 'candidate subset' are specific, and the constraint type (one-sided resource chance constraints) adds differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for problems involving independent-Gaussian chance constraints, but it does not explicitly state when to use this tool versus alternatives such as athena_dro_resource_select or athena_two_stage_resource_plan. No exclusions, prerequisites, or alternative tool names are given, so the usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core behavior (exact one-step advancement) and per-step evidence requirements, which is useful. However, it does not mention failure modes, reversibility, side effects, or what happens when prerequisites are unmet—important for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single core statement and a compact three-line mapping. Every symbol and phrase carries meaning, and the most important constraint ('exactly one') is front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the schema (nested test object, evidence array with kinds, canonical_authority, actor) and lack of an output schema, the description is too sparse. It does not explain how parameters interact, when the test object is needed, what actor means, or what the tool returns, leaving a substantial comprehension gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only implicitly references two of six parameters (evidence and canonical_authority via the transition map). Parameters like claim_id, target_y, test, and actor are left unexplained, leaving the agent to guess their roles from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear action ('Advance exactly one authority step') with explicit scope ('exactly one'), and maps the three possible transitions using intuitive arrow notation. It does not explicitly name sibling tools for differentiation, so it misses the top score, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies context by stating prerequisites for each transition (?->+ needs verified evidence, etc.), but it does not explicitly say when to favor this tool over alternatives like athena_claim_challenge or athena_claim_register. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. It mentions a 'declared model' but does not disclose whether the tool modifies state, what the return value looks like, how randomness is controlled, or prerequisites for 'context_key.' This is a significant gap for a decision-making tool that likely returns a value or writes to state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically correct sentence that front-loads the main verb and key concepts. It contains no redundant words or filler, earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (four parameters, no output schema, no annotations), a 15-word description is inadequate. The agent cannot determine what context_key references, what format actions should take, how samples and seed affect the outcome, or what the return value represents. The description is far from sufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (context_key, actions, samples, seed). While 'Monte Carlo' implies the role of samples and 'declared model' hints at context_key, the semantics of actions and seed are unclear, and no guidance is provided for constructing valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates 'expected value of perfect information' via 'Monte Carlo' under a 'Gaussian linear belief and utility model.' It uses a specific verb ('estimate'), names the exact quantity (EVPI), and differentiates from sibling tools like athena_decision_evsi and athena_decision_evi by focusing on EVPI. The method and model context are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context (Monte Carlo under a Gaussian linear model) that implies when this tool is applicable, but it does not explicitly state when to use it versus alternatives such as athena_decision_evsi or athena_decision_evi. No exclusions or alternative references are given, so guidance is only implied from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. The verb 'Return' implies a read-only operation, but the description does not explicitly confirm safety, clarify whether computation occurs, or explain side effects. It does add some context about reliability and causal-weight metadata, but this is more about output content than behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action ('Return') and packs the key qualifiers without redundancy. Every word contributes to understanding the tool's output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a highly specialized domain, the description leaves gaps: it does not specify the structure of the returned matrix, the meaning of 'learned/shrunk', or how reliability and causal-weight metadata are presented. It is adequate for a surface understanding but not fully self-sufficient for an agent needing to interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, so the 100% schema coverage is trivial. The description adds meaningful context by explaining what the returned data represents, which compensates for the empty input schema. A score of 4 reflects the baseline for zero-parameter tools with no param semantics needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and clearly identifies the resource ('learned/shrunk token-artifact-module-domain-system diffusion coefficients') with additional metadata qualifiers. It distinguishes from most siblings by focusing on a matrix of diffusion coefficients rather than observation or simulation, though it doesn't explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as athena_diffusion_observe or athena_coordinate_matrix. The description only states what it returns, with no mention of scenario fit, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It labels the operation as 'read' (suggesting non-mutating) but does not explain what the 'active witnessed relation/conflict head' means, whether there are prerequisites, what the response looks like, or how errors are handled. The jargon is unexplained for an AI agent unfamiliar with the equivalence domain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words or filler. It is appropriately short for what it conveys, though the density of domain jargon means it could benefit from a bit more explanation without being wordy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete given the tool's complexity and the absence of annotations, output schema, or rich sibling context. It does not explain what the 'head' represents, what the tool returns, or how it fits into the equivalence workflow (observe, resolve, snapshot). This is insufficient for an agent to know the full behavior and expected output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the three parameters (context_id, left_id, right_id). It mentions 'one unordered pair' and 'dedup context', which likely map to the IDs and context, but it does not explicitly define each parameter's meaning or relationship. The description adds minimal value over the raw parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('read') and identifies the precise resource: the active witnessed relation/conflict head for one unordered pair in a dedup context. This clearly distinguishes it from sibling tools like athena_equivalence_observe or athena_equivalence_resolve_conflict.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read/query use case but does not explicitly state when to choose this over alternatives (e.g., athena_equivalence_snapshot or athena_equivalence_observe). It gives some context ('one unordered pair', 'dedup context') but lacks exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects, persistence, idempotency, or any requirements. It only states the action and purpose, leaving the agent without knowledge of what happens when the tool is invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is concise and front-loaded, with no redundant words. It earns its place but is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, nested objects, and no output schema or annotations, the description is far too minimal. It provides no guidance on parameter values, return behavior, or ordering, making it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; the description does not mention any of the five parameters (scope, features, label, weight, evidence_ref) or explain their meaning. The schema alone is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('record') and resource ('externally labelled evidence-dependence example'), and states the purpose ('for later empirical calibration'). This clearly distinguishes it from sibling tools like predict/fit/interval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for recording labelled examples for calibration, which provides clear context but does not explicitly state when not to use it or compare with alternatives like athena_evidence_dependence_predict.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention what happens if no fitted model exists, the output format or structure, or whether there are any side effects. The description is too terse to convey important behavioral aspects for a prediction tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core action. It contains no filler or redundant wording, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has complex nested parameters, no output schema, and no annotations. The one-line description fails to explain critical aspects such as the format of 'features', the meaning of 'scope', or what the prediction output looks like. This is inadequate for an agent to use the tool confidently, even compared to similar tools in the same family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description provides no information about the 'scope' or 'features' parameters. The nested 'features' object is especially ambiguous, leaving the agent without any guidance on the expected structure or content. The description does not compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Predict pairwise evidence dependence under a previously fitted scoped calibration model.' It uses a specific verb ('predict') and resource ('pairwise evidence dependence'), and the prerequisite of a fitted model distinguishes it from sibling tools like athena_evidence_dependence_fit or athena_evidence_dependence_observe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'under a previously fitted scoped calibration model' implies that the tool should be used after a fitting step, providing clear context for when it is applicable. However, it does not explicitly mention alternatives or when not to use it, such as when an interval or probability estimate is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Fetch' implies a read-only operation, and the description enumerates the contents of the returned GAPRUN, adding behavioral context about what is included. However, it does not explicitly state safety (e.g., 'does not modify state') or clarify any absence of 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the core action and the key content areas in 22 words, earning its place entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with one parameter and no output schema, the description is fairly complete: it identifies the resource and lists what is returned (snapshot, closure paths, residuals, grow decision, digest). It lacks an explicit note that the output is a single object, but the singular 'one GAPRUN' covers that. No error behavior is mentioned, but for a read tool this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (run_id, string, minLength 1) but schema description coverage is 0%, meaning the parameter lacks any description. The tool description does not mention run_id by name or explain how to identify the GAPRUN, relying on the implication from 'one persisted GAPRUN'. This is insufficient given the schema provides no help.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and resource ('one persisted GAPRUN') with specific qualifiers (exact snapshot, closure paths, residuals, grow decision, digest). It is distinguishable from siblings like athena_gap_recent and athena_gap_replay by focusing on a single persisted run, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this is for fetching a specific run by ID, nor does it direct users to athena_gap_recent for listing recent runs or athena_gap_replay for replays. Clear selection criteria are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden and does disclose meaningful behavioral traits: the prediction is deterministic, uses a FITC approximation, and exposes query-level error. However, it omits side effects, prerequisites, return structure, and the meaning of 'bounded GP reference,' leaving important behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is efficient, front-loaded, and contains no filler. It packs the core purpose and distinguishing output into a compact statement, though the dense jargon and undefined 'bounded GP reference' reduce clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with a nested features object, no output schema, and no annotations, but the description provides no details on parameter values, return shape, or usage context. The sparse description is insufficient for an agent to invoke it correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (context_key, features, inducing_count, include_observation_noise). The high-level FITC context provides no guidance on how to construct the features object, what context_key refers to, or how inducing_count affects predictions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool predicts using a deterministic inducing-point FITC GP approximation and exposes query-level error against an exact bounded GP reference. This specifies a unique verb, resource, and method, distinguishing it from sibling GP predictors like athena_gp_predict and athena_gp_sparse_predict.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for FITC-based prediction with error analysis against a bounded GP reference, but it does not explicitly state when to use it over alternatives or provide exclusion criteria. The guidance is implicit rather than actionable, leaving the agent to infer usage from the sibling tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose that the tool registers/resets model state, is exact and small-data oriented, and uses fixed RBF kernel hyperparameters. However, it does not mention whether resetting overwrites existing state, what the return value is, or any error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. It front-loads the main action and resource, then adds a crucial limitation ('Model state only'). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, no annotations, no output schema, and many closely related siblings. The description is far too sparse to provide adequate context for an agent to know when to use it, what parameters mean, what side effects occur, or what to expect back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It hints at 'fixed RBF kernel hyperparameters', which likely maps to length_scale, noise_variance, and signal_variance, but it does not explain the other parameters such as context_key, features, replace, or metadata. This is insufficient for a 7-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verbs 'Register/reset' and identifies the resource as an 'exact small-data Gaussian-process regressor with fixed RBF kernel hyperparameters'. This clearly distinguishes it from prediction/observation siblings like athena_gp_predict or athena_gp_observe, though it does not name any sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Model state only' provides an implicit usage boundary, indicating this tool is not for prediction or hyperparameter fitting. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the selection logic (shallowest tested representation, decision-margin constraint) but omits side effects, state changes, or what 'tested' entails. Adds some context but not rich detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that is front-loaded and contains no filler. It manages to convey purpose and a key constraint efficiently, though it sacrifices clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description is far too sparse. It leaves critical questions about parameter meanings, return values, and operational semantics unanswered, making it inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It only loosely maps to 'actions' (action/query set) and 'margin_safety' (decision-margin error rule), leaving context_key, inducing_counts, and include_observation_noise unexplained. Insufficient compensation for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool chooses a representation ('shallowest tested FITC/full-GP') based on decision preservation, using specific verbs and resources. It distinguishes from GP prediction/observation siblings by focusing on representation selection, though the jargon limits accessibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing a GP representation that preserves decisions on a given action/query set, and mentions a decision-margin error rule. However, it gives no explicit alternatives or when-not-to-use guidance, relying on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses the cross-fitting procedure, bounding, and validation approach, but omits return values, error conditions, and side effects. The scope caveat is useful but the operational behavior is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences that front-load the core method and add a scope caveat, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with 11 parameters, nested objects, and no output schema, yet the description provides only a two-sentence summary. It fails to explain required inputs, how to interpret results, or the assumptions behind the method.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description explains none of the 11 parameters such as treatment1, intermediate, treatment2, regimes, assumptions, or propensity_clip. The phrase 'two-timepoint' is too high-level to map to any specific parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Cross-fit') and a precise resource ('bounded binary two-timepoint sequential logistic TMLE'), with details on held-out folds and baseline/time-order validation. This clearly distinguishes it from general longitudinal TMLE tools like athena_longitudinal_tmle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives some context by scoping to bounded binary two-timepoint sequential designs and warning that it is 'Assumption-scoped; not a general longitudinal TMLE theorem.' However, it does not explicitly state when to prefer this over alternatives or list exclusion criteria, leaving the guidance partial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the tool returns a law and lists coverage areas, but it does not explicitly mention that the operation is read-only, describe the return format, or note any side effects or prerequisites. The verb 'Return' implies safety, but explicit behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and object. It enumerates many topics, making it slightly dense, but every phrase contributes useful information. There is no redundant or filler content, so it earns a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a parameterless retrieval tool with no output schema, the description explains what is returned and the topics covered, which is sufficient for an agent to decide whether to invoke it. It could be improved by mentioning the return format or whether the law is a plain text document, but the scope list provides adequate context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the empty schema fully covers the interface. The description adds no parameter-specific semantics, but none are needed. The baseline for 0 parameters is 4, and the description appropriately provides scope context without confusing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Return' and identifies the resource as 'canonical unified MAXDEV execution law', which clearly states what the tool does. It also lists the areas covered, adding specificity. However, it does not explicitly distinguish itself from sibling tools, so it scores a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance or reference to alternatives. The description implies it should be used when the canonical execution law is needed, but offers no exclusions or comparisons to sibling tools. This leaves the agent without clear selection criteria beyond the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool updates models, but does not mention side effects, persistence, idempotency, or any potential consequences. This is a minimal disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and free of unnecessary words. It efficiently communicates the core action without fluff, though this brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, 4 required, nested objects, no annotations, and no output schema, the description is grossly underspecified. It does not explain return values, side effects, or how to correctly invoke the tool, making it nearly impossible for an agent to use correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain the meaning of any of the 9 parameters. It only conceptually hints at 'explicit observed reward' and 'raw-feature OOD reference distribution' but does not map these to specific parameters like reward, features, or regime. The description adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Update') and specific resources ('degree-2 Bayesian model', 'raw-feature OOD reference distribution'). It distinguishes itself from sibling tools like athena_transition_observe or athena_bayes_observe by naming the exact model and distribution being updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when an explicit observed reward is available and the model/distribution need updating. However, there is no explicit guidance on when to prefer this over alternatives or when not to use it, leaving the context only vaguely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral outcome (certification of specific properties) and notes the conditional exact treewidth value when a matching clique lower bound is present. However, it does not mention any side effects, error handling, or prerequisites, but since verification is inherently a read-only operation, the absence of destructive disclosures is acceptable. With no annotations, the description provides a moderate level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs several technical concepts, but it is not overly verbose and clearly states the primary action first. It earns its place without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema), the description provides only a high-level summary. It does not explain how the parameters map to the certification criteria, what inputs are required, or what the return value looks like, making it insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 7 parameters with 0% description coverage. The description does not reference any parameter names or explain the meaning of 'patches', 'bags', 'conflicts', etc., leaving the agent to infer from names alone. The phrase 'supplied tree decomposition' hints at 'bags' but does not clarify required vs optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Verify' with a clear resource ('tree decomposition') and enumerates the specific certification criteria (factor coverage, running intersection, width upper bound, exact treewidth value), making its purpose unambiguous and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not specify when to use this tool instead of alternatives, nor does it mention any exclusions or prerequisites beyond describing the core verification task. No alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the solve method (local component enumeration + Pareto-pruned Minkowski convolution) and a specific guarantee (preserves every scalar-policy tie). However, it does not disclose whether the operation is read-only, mutates state, requires permissions, or has failure modes, leaving key safety/behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that leads with the main verb 'solve' and packs the algorithm and key guarantee into 16 words. Every phrase adds distinct information, and there is no filler or tangential detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 8 parameters, no output schema, and no annotations, the description is far too brief. It does not specify what the solver returns (a solution set, a policy, etc.), what 'supported' entails, or how conflicts/dependencies are handled. The agent lacks essential context to invoke the tool correctly beyond the raw schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention or explain any of the 8 parameters (mode, policy, patches, conflicts, etc.). The algorithm hint 'local component enumeration' loosely relates to max_component_size, but the mapping is not explicit. The self-documenting schema provides types and constraints, but the description fails to add meaningful semantics for how parameters affect the solve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('solve') and resource ('supported disconnected Boolean QHUG kernel'), with an algorithmic qualifier. It clearly distinguishes the tool from sibling analyzers/verifiers by focusing on exact solving rather than analysis or verification. However, the heavily specialized terminology leaves ambiguity for agents unfamiliar with the domain, preventing a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it is for exactly solving a supported disconnected Boolean QHUG kernel. However, it provides no explicit when-to-use vs alternatives, no exclusions, and no mention of prerequisites or limitations. The guidance is purely implicit through the object being solved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It provides meaningful details: fresh-sync, consuming an exact delta, rejecting drift, hydrating only the affected cone, and falling back to full rehydration. This exceeds typical minimal disclosures, though it omits mutation/side-effect specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—two sentences with no fluff. It front-loads the core action and adds a conditional fallback. The language is dense and jargon-heavy, but it earns its place by conveying multiple behavioral aspects succinctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no annotations, and no output schema, this description is a high-level overview but insufficient. It does not describe return values, prerequisites, side effects, or the meaning of parameters like shared_remote_mode and include_frontier_on_change. The agent would struggle to invoke it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain any of the 6 parameters. Terms like 'handoff delta' and 'dependency cone' hint at concepts but do not map to loop_id, expected_handoff_digest, remote, shared_remote_mode, or the include_* flags. The agent is left without any parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool performs a rehydration operation using an exact handoff delta, with explicit behaviors like rejecting drift and hydrating a dependency cone. It suggests this is distinct from related tools like athena_rehydration_handoff_delta or athena_rehydration_resume, though the exact distinction is not fully spelled out.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when a handoff delta is expected and rehydration is needed) and includes a fallback condition. However, it does not explicitly contrast with alternatives like athena_rehydration_start or athena_rehydration_resume, nor state preconditions such as 'use only if a handoff delta exists' or 'do not use when...'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses read-only nature, local scope, and the limitation that PASS is not an external attestation. However, it does not explain return values on failure or any other side effects, leaving gaps for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence, front-loaded with the main action and purpose. It packs details efficiently without redundant filler, though the technical abbreviations may require domain knowledge.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a clear purpose and a key limitation, but for a tool with no output schema and 2 optional parameters, it doesn't explain how to interpret the result beyond PASS/FAIL or how parameters affect the run. It's adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It mentions 'COMPOSITION.2' and 'deterministic replay samples,' which likely map to run_composition_probes and replay_limit, but it doesn't explicitly connect them. Parameter semantics rely heavily on inference from names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a specific health synthesis (ATHENA.SELFTEST.1) and enumerates the components it checks. The verb 'Run' and the resource 'read-only local health synthesis' are specific, but it does not explicitly contrast with sibling tools like athena_startup_health, so it falls 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternative tool references. The caveat about PASS not substituting for external CI implies a limitation but doesn't direct selection among siblings, so the guidance is implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the computation and inputs. It does not disclose the return format, assumptions (e.g., positive risk ratio), handling of invalid inputs, or any other behavioral traits, which is a significant gap for a standalone tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently states the verb, resource, and parameters in about 20 words, earning its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough to understand the tool's basic action and inputs, but it omits output details (e.g., what the E-value looks like) and any caveats or edge cases. Given the absence of an output schema and annotations, a slightly richer description would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the bare schema by mapping risk_ratio to 'point estimate' and ci_limit to 'optional closest-to-null CI limit.' This compensates for the 0% schema description coverage, though it could specify units or constraints for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes the standard risk-ratio E-value sensitivity metric, identifying the specific metric and inputs (point estimate and optional CI limit). However, it does not explicitly differentiate from the sibling tool athena_sensitivity_rr_surface or other sensitivity metrics, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as athena_sensitivity_rr_surface. The description gives no context, prerequisites, or exclusions, leaving the agent without criteria for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does reveal the estimation method, cross-fitting, and policy constraints. However, it does not clarify whether the tool is read-only, what 'PLAN_ONLY' means, or what is returned. The assumption-scoping hint is useful but underdeveloped.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, and the main function is front-loaded. The heavy jargon reduces clarity, but it remains compact and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, nested objects, no output schema), the description is insufficient. It omits required input structure, return format, and clear explanations of 'PLAN_ONLY' and 'assumption-scoped'. An agent would struggle to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain most parameters. It provides indirect clues (e.g., A1 and A2 policies map to baseline/treatment1/intermediate/treatment2), but leaves samples, folds, seed, propensity_clip, and assumptions undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool estimates a deterministic two-timepoint dynamic-policy value using out-of-fold sequential AIPW. It clarifies the policy structure (A1 uses baseline, A2 uses baseline+A1+L1) and distinguishes from siblings like athena_sequential_dr_policy_value by mentioning crossfit/out-of-fold.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are mentioned. The A1/A2 policy constraints describe allowed policy inputs, not usage scenarios. 'PLAN_ONLY' and 'assumption-scoped' are vague and do not help an agent choose between this and similar estimators like athena_longitudinal_tmle_crossfit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does mention two important behaviors: the rollback operates under 'current-version CAS' (implying concurrency checks via expected_version) and that the rollback is preserved as a 'new witnessed transaction.' However, it omits side effects, permissions, error conditions, and return behavior, leaving significant ambiguity for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, action-oriented sentence with no wasted words. It front-loads the primary verb and resource, then packs two key constraints (CAS and witnessed transaction) into a compact phrase. The terminology is dense but appropriate for a specialized tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of CAS, witnessing, and topology transactions, plus the absence of annotations and output schema, a one-sentence description is insufficient. It does not explain return values, failure modes, parameter semantics, or how exactly the CAS/witness behavior works, leaving the agent with many unknowns for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (topology_id, txid, expected_version, actor). While 'current-version CAS' hints at expected_version's role, none of the parameters are defined, making it impossible for an agent to understand how to populate them correctly without external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function—rolling back a prior collective topology transaction—and differentiates it from sibling tools like athena_policy_rollback by specifying 'collective topology' and the CAS/witnessed transaction context. The verb 'Rollback' and the resource 'prior collective topology transaction' make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (rolling back a prior collective topology transaction under current-version CAS) but does not explicitly state when to use this tool versus alternatives like athena_policy_rollback or athena_topology_apply. It also lacks explicit exclusions or conditions, so usage guidance is inferred rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It adds meaningful behavioral context by stating that 'Alarm transport is not proof of falsity, causal dependence or logical entailment' and that 'missing residual metrics remain for measurement', but it omits side effects, permissions, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and the second sentence adds an important epistemic caveat. Every clause contributes information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a clear purpose, the description lacks usage guidance, parameter detail, and output expectations. With no annotations or output schema, and many sibling transport tools, this description is insufficient for an agent to know exactly when to invoke it and how to parameterize it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain individual parameters like 'actor' or 'persist'. It only alludes to 'explicit alarmed nodes' (alarm_nodes) and 'alarm provenance' (alarm_ref), leaving required parameters underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Convert' with clear resources: 'explicit alarmed nodes' into 'GAP target/revalidation pressure'. This makes the purpose unambiguous even among many transport siblings, though it does not explicitly differentiate from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when alarm nodes need to become GAP pressure, but provides no explicit when-to-use or when-not-to-use guidance, nor does it reference alternative transport tools. The caveat about provenance hints at conditions but does not state them directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: PLAN_ONLY (no side effects on belief), exact finite-model/outcome tree, and bounded horizon <=3. This is valuable context, though it omits details about return format or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every word earns its place. It is appropriately concise without wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 5 parameters, no output schema, and no annotations, the description is too sparse. It explains what the tool builds but not how to use it: parameter semantics, return value, or when it should be selected over the many sibling planning/belief tools. The completeness is insufficient for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no information about the five parameters (actions, horizon, discount, context_key, information_weight). The agent is left without any guidance on what values to provide or what these parameters control, making this dimension critically deficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an exact finite-model/outcome belief-policy tree for bounded horizon <=3, which is specific and action-oriented. It distinguishes itself from sibling tools by mentioning the multistage belief-policy tree and PLAN_ONLY mode, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: for building a plan-only belief-policy tree with horizon <=3, and explicitly notes no belief mutation. However, it gives no explicit when-to-use vs alternatives or exclusions, such as when to prefer a different policy tool or when horizon >3 is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions applying a hibernation/resurrection policy but does not explain what this does to the branch, whether it is reversible, or any side effects. The behavior is not transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that efficiently conveys the core action without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 8 parameters, no output schema, and no annotations, the description is too terse. It does not describe return values, policy effects, or prerequisites, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only indirectly references reward and witness. It does not explain branch_id, basis_id, policy, actor, metadata, or triggers. The meaning of 'calibrated' and the structure of witness are not elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: record a witnessed calibrated branch reward observation and apply an EWMA policy. It distinguishes from sibling observe tools by specifying 'branch reward' and the policy component.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a branch reward observation is witnessed, but it does not provide explicit guidance on when to choose this over alternatives like athena_transition_observe or athena_belief_observe. No when-not-to-use 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool replays bindings and only verifies receipt structure, not cluster observation, but it does not state whether the operation is read-only, what side effects it might have, or what happens on failure. This leaves significant uncertainty for an agent deciding whether to invoke the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with only two sentences, and the primary action is front-loaded. The second sentence is terse and somewhat cryptic ('PASS verifies receipt structure') but still adds a key distinction. Overall, it is efficient without unnecessary preamble.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six required parameters, no output schema, and no annotations, yet the description provides no parameter explanations, return value details, or error handling context. This is a verification tool, so an agent would need to know what a PASS/FAIL means, what the success criteria are, and how to interpret the replayed bindings. The description is far too sparse for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and the tool description does not mention any parameters. Although parameter names like 'expected_plan_digest' and 'expected_source_head' are somewhat self-explanatory, the description provides no additional meaning or context about how they relate to the receipt or how to format them. This is a significant gap given all six parameters are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: replaying the exact plan/image/source/state bindings of an activation receipt. It also distinguishes itself from independent cluster observation, which differentiates it from sibling verification tools. The verb 'replay' and the resource 'activation receipt' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: to verify receipt structure. It explicitly excludes independent cluster observation, helping the agent avoid misusing it. However, it does not name alternative tools or provide explicit 'when not to use' guidance beyond that exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It explicitly reveals a side effect beyond the 'observe' name: updating the diffusion coefficient. However, it does not detail reversibility, authorization needs, or what else might be affected by the update.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler or repetition. It is front-loaded with the action and object and imparts the essential purpose without extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, no annotations, no output schema, and a complex domain, the one-sentence description is underspecified. It omits parameter semantics, return behavior, and practical usage conditions, making it difficult to invoke reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only alludes to source_scale, target_scale, and transfer_utility through 'two scales' and 'utility'. It leaves actor, evidence_weight, and causal_confidence entirely unexplained, so it does not compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'Record' and 'update' with a clearly identified resource: 'pheromone transfer between two scales' and 'a shrinkage-learned diffusion coefficient'. This uniquely distinguishes it from sibling observation tools like athena_bandit_observe or athena_transition_observe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as athena_diffusion_matrix or athena_pheromone_reinforce. It lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage solely from the action described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says the tool 'selects' a subset and enumerates exactly below a threshold, but it does not disclose side effects, output format, error behavior, or what happens when the threshold is exceeded. This is too thin for a complex selection tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with the core action front-loaded and no filler. Every phrase contributes essential information about the mathematical model and the enumeration limit, making it highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity tool with 6 parameters, nested objects, and no output schema, yet the description is only one sentence. It omits return values, parameter formats, exact behavior above the threshold, and any prerequisites or failure modes. An agent lacks critical information needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It maps a few concepts to parameters (covariances, ambiguity_radius, exact_limit), but it does not explain required params like candidates, budgets, and covariances, nor the optional alpha parameter. The domain jargon gives hints but not enough semantic grounding for an agent to construct valid arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action ('Select a finite candidate subset') and names the exact problem setting ('correlated Gaussian resource covariance plus ellipsoidal mean ambiguity'), which clearly distinguishes it from sibling tools like athena_chance_resource_select and athena_two_stage_resource_plan. It also states a scope condition ('exact enumeration only below the declared threshold'), making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the appropriate context for use: DRO resource selection with Gaussian covariance and ellipsoidal ambiguity, plus a limiting condition about exact enumeration. However, it does not explicitly state when to prefer this tool over alternatives, nor what to do when the threshold is exceeded. Thus it provides clear context but no exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of disclosing behavior. It only offers the cryptic qualifiers 'Assumption-scoped and PLAN_ONLY' and does not explain return values, side effects, permissions, or computational implications. This is insufficient for a complex statistical tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences with the core function front-loaded. There is no filler, and every phrase adds information, even if the information is cryptic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, nested object schemas, no output schema, and no annotations, the description provides only a high-level method and mode. It does not describe expected outputs, the structure of samples or policies, or how assumptions are specified, leaving major gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not define any individual parameters. While 'two-timepoint' loosely maps to treatment1/treatment2 and 'policies' to the policies parameter, the roles of samples, intermediate, baseline, and assumptions remain undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Value') and identifies a precise resource ('deterministic two-timepoint treatment policies') and method ('bounded longitudinal parametric g-formula'). This distinguishes it from related tools like athena_longitudinal_gformula and athena_sequential_dr_policy_value by scope and method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Assumption-scoped and PLAN_ONLY' conveys a context constraint (planning only, under assumptions), but it does not explicitly state when to use this tool versus alternatives or provide exclusions. No sibling tools are referenced as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It adds a valuable behavioral trait: ranking is evidence-based, not age-based. However, it does not disclose other traits such as side effects, permissions, or return format. This is minimal but meaningful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence. Every word adds value: the verb 'Rank', the object 'elder/cultural authority', the qualifier 'evidence-backed', and the scope. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no required parameters, no output schema, and no annotations, the description is too sparse. It does not explain the meaning of 'limit' or 'min_observations', the ranking criteria beyond 'evidence-backed', or what the returned ranking looks like. The agent would struggle to use this tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only implies the 'scope' parameter via 'within a scope', leaving 'limit' and 'min_observations' entirely unexplained. This is insufficient for an agent to correctly invoke the tool with all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: ranking elder/cultural authority based on evidence within a scope. It highlights a key behavioral distinction (age alone confers no authority), which differentiates it from a naive age-based ranking and from sibling tools like athena_elder_observe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description implies use for ranking evidence-backed authority but provides no exclusions, prerequisites, or comparisons with sibling tools. The agent must infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It adds one useful behavioral disclosure: 'private chain-of-thought is neither requested nor stored,' which conveys a privacy guarantee. However, it doesn't mention side effects, permissions, or the nature of 'liminal telemetry,' leaving much undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with two tightly packed clauses. It front-loads the core purpose ('Emit public liminal telemetry') and adds the privacy clarification without wasted words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, nested objects, no output schema), the description is under-specified. It does not explain what 'liminal telemetry' means, how to fill the required parameters, or what the tool returns. The context provided is too sparse for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides no parameter-specific details. It references 'agent task' but never maps to the 15 schema properties (e.g., seq, intent, action, status), so the agent must rely on parameter names alone, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Emit') and resource ('public liminal telemetry for an agent task'). It distinguishes from siblings by explicitly noting that private chain-of-thought is neither requested nor stored, which narrows its scope relative to other athena_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for agent task telemetry, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it name alternative tools. With many sibling tools, some exclusionary context would help but is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the tool is 'DESIGN_ONLY', implying no experiment execution or side effects, which is useful. However, it does not specify whether the operation is read-only, mutates state, requires authentication, or what the output format is, so transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the primary action, then provides essential detail (inputs and ranking), and ends with a clear design-only flag. There is no redundancy, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and no annotations. The description gives a clear high-level summary but omits details on return values, optional parameter roles, and usage constraints. It is adequate for understanding the core purpose but not sufficient for fully informed invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for 'factors' and 'hypotheses' by referencing 'caller-declared factor levels' and 'hypothesis factor-effect models', but it leaves cost_weight, risk_weight, sample_size, and max_candidates unexplained, providing only partial parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Generate') and resource ('candidate experiments'), and details the process (from factor levels and hypothesis factor-effect models) and ranking criterion (V5 expected information gain). It is distinct from generic experiment tools, though it does not explicitly compare to sibling 'athena_experiment_design'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The sibling list includes 'athena_experiment_design' and other related tools, but the description provides no conditions, prerequisites, or exclusions, leaving the agent to infer usage context on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It states that missing event coverage or contract drift fails closed and never manufactures readiness, which is useful transparent behavior. However, it does not mention whether the operation is read-only, has side effects, or requires permissions, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action and scope. No unnecessary words or repetition; every clause adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five undocumented parameters and no output schema, yet the description only covers the selection criterion and fail-closed behavior. It does not explain domain terms like 'SCHED V3' or 'replayably READY', nor does it clarify what 'Pareto frontier' means here, making the description incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the five parameters (task, fetch, remote, profile, source_ref). Parameter names are not self-explanatory in context, and there are no enums or descriptions to help the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a Pareto frontier, restricted to replayably READY SCHED V3 nodes. It uses a specific verb ('Return') and specifies the resource and scope, distinguishing it from broader frontier tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used when you need a Pareto frontier over ready nodes only, not all nodes, but it does not explicitly mention alternatives or when-not-to-use conditions. The 'only' qualifier gives some guidance, but no exclusions or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the transparency burden. It discloses the important limitation that missing cells remain UNIDENTIFIED, but does not state whether the operation is read-only, whether it has side effects, or any permission requirements. The verb 'Compute' hints at a non-mutating operation but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences that both add value: the first states the core function, and the second provides a critical caveat. It could be slightly more structured, but there is minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is not complete enough for autonomous use. It lacks details on return values, how to interpret contrasts, and the role of design_confidence. The missing-cell warning helps but does not compensate for the overall lack of context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for parameter meaning. It loosely maps 'order-2..4' to max_order and 'Every 2^k cell' to experiments, but design_confidence is entirely unexplained. The mapping to experiments is also indirect and not clear enough for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes 'order-2..4 factorial inclusion-exclusion contrasts', a specific statistical operation. It also provides a key distinguishing constraint ('Every 2^k cell is required'), but does not explicitly contrast with sibling tools like athena_interaction_credit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by requiring a full 2^k factorial design and warns that missing cells lead to UNIDENTIFIED results. This serves as a practical precondition but stops short of naming alternatives or explicitly stating when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It provides only a high-level caveat about being assumption-scoped, but fails to disclose what the output looks like, what assumptions are required, whether it is read-only or has side effects, or what failure modes might occur. For a complex statistical tool, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, consisting of two sentences that each add value: the first states the core action, target, and method; the second qualifies the scope. There is no filler or redundant information, and it is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, no annotations, no output schema, and many closely related sibling tools), the description is far too brief. It does not specify assumptions, output format, parameter meaning, or differentiating use cases. An agent would struggle to correctly invoke this tool or choose it over similar longitudinal TMLE tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description does not explain any of the 9 parameters directly. It hints at the roles of treatment1, treatment2, and outcome through the purpose statement, but leaves samples, intermediate, assumptions, propensity_clip, regimes, and baseline undefined. It does not compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Estimate static two-timepoint binary treatment-regime risks' with a specific method 'sequential logistic targeting'. It distinguishes itself from siblings by specifying 'static' (vs dynamic), 'two-timepoint' (vs general longitudinal), and 'binary treatment', while also noting it is 'not a general longitudinal-TMLE theorem', which separates it from more general tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for static two-timepoint binary treatment-regime risk estimation and warns that it is 'assumption-scoped'. However, it does not explicitly state when to use this tool over alternatives like athena_longitudinal_tmle_crossfit or athena_longitudinal_gformula, nor does it provide exclusion criteria or specific use cases beyond the general purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It usefully discloses that unavailable components remain UNKNOWN, providing one behavioral trait. However, it doesn't state whether this is a read-only operation, whether it has side effects, or how the packet structures missing data, leaving significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loads the core action. While the first sentence is a dense list of domains, each item adds meaning and the entire description stays succinct without redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool without an output schema, the description lists the covered state categories and notes UNKNOWN for unavailable parts, which is helpful. However, it doesn't explain the packet's structure, how to interpret the output, or what 'accessible' means, leaving gaps for a potentially complex projection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. There are no parameter semantics to clarify, and the description appropriately focuses on output rather than inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool projects current accessible ATHENA runtime state into an Ω packet, listing specific domains (semantic head, Git, base/crystal, Collective, etc.). This gives a specific verb and resource, and the comprehensive scope distinguishes it from more narrowly scoped sibling state tools like athena_branch_state or athena_cycle_state, though it doesn't explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many other state-related sibling tools. It doesn't mention alternatives, exclusions, or the appropriate context for calling this projection instead of a more specific state tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses 'bounded,' 'limited Meek orientation,' and 'Hypothesis graph only,' which gives useful caveats about the algorithm's scope. However, it does not mention return format, failure modes, or runtime behavior, leaving gaps for a discovery tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. Every word adds technical substance, making it appropriately concise for the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the algorithm complexity, there is no output schema and no annotations. The description neither explains what 'Hypothesis graph only' means in practice nor describes parameter semantics, input expectations, or output structure. It is far too sparse to fully guide an agent for a 4-parameter causal discovery tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explicitly explain any of the four parameters. 'Bounded' and 'Fisher-z tests' only indirectly relate to max_conditioning and alpha, but the description adds little concrete meaning beyond what the schema already shows (names and types alone).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Run') and names the exact algorithm variant (PC-stable, Gaussian, Fisher-z, limited Meek orientation). It also explicitly states 'Hypothesis graph only,' which distinguishes it from sibling tools like athena_fci_lite_discover or athena_pag_candidate_discover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or name sibling tools for comparison. The brief algorithm mention implies usage but provides no actionable 'use this when...' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only states 'Read' and mentions 'recovery state' without disclosing any behavioral traits such as side effects, error handling, or what actions are safe. It does not go beyond the inherent read-only implication or explain what 'recovery state' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'Read', and contains no filler words. It effectively communicates the core action and resource in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 must clarify what the response contains, but it does not explain the structure of 'recovery state' or what fields or statuses might be returned. Given the tool's status-read nature and the existence of many sibling status tools, the missing return information leaves the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the sole parameter 'projection_id' is only typed as string. The description alludes to the concept of a 'projection saga' but does not clarify what constitutes a valid ID, any format requirements, or the meaning of 'projection_id' in this context. The description only partially compensates for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' and a clear resource: 'one topology-to-JSPACE projection saga and its recovery state.' This precisely identifies the tool's function and distinguishes it from other status tools like athena_git_status or athena_policy_state by the 'projection saga' and 'recovery state' qualifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading the status of a projection saga, but it does not provide explicit guidance on when to use this tool versus related tools such as athena_projection_prepare, athena_projection_compensate, or athena_topology_project_jspace. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It discloses a sequence of state-mutating actions (verify, persist, rehydrate, compile), giving insight into side effects. However, it omits failure modes, behavior on verification mismatch, and whether the operation is destructive or reversible, leaving significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with no wasted words. It is front-loaded with the trigger condition and packs the main actions into a compact sequence. While it could benefit from list formatting for readability, it remains appropriately concise for a high-level summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested completion object, required digests, no output schema, no annotations), the high-level summary is insufficient. An agent cannot infer how to build the completion payload, what 'observed pass receipts' means, what the expected digests represent, or what the tool returns. Sibling tools imply a detailed protocol that this description fails to convey.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 9 parameters, the description must compensate but does not. It never references parameter names, fails to explain expected_checkpoint_head, expected_state_digest, or expected_prompt_digest, and provides no guidance on constructing the nested 'completion' object. The only indirect hints are 'verify checkpoint ancestry' and 'pass receipts,' which are not mapped to specific fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's role: advancing the rehydration cycle after a completed self-prompt. It lists specific actions (verify ancestry/pass receipts, persist cycle, rehydrate Git head, compile next prompt) that distinguish it from sibling rehydration tools, though the heavy jargon assumes domain familiarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening clause 'After an agent completes the current self-prompt and commits substantive work' provides a clear, explicit precondition for use. It does not mention when to avoid using it or name alternatives, but the trigger condition is well-defined and adequate for most invocation decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Read-only' and warns that 'bootstrap frequency is not a causal posterior,' which are valuable behavioral disclosures. With no annotations provided, these clarifications help the agent understand side effects and interpretation. However, it does not cover other behavioral aspects like computational cost or determinism.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and output, and includes a caveat. Every word earns its place; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the description is too thin for an agent to invoke correctly. It does not explain what 'bounded V13 FCI-lite' means, what the return object looks like, or what the parameters do. It only gives a high-level summary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation for any of the 7 parameters (seed, alpha, samples, variables, bootstrap_runs, max_conditioning, stable_threshold). The description adds no meaning beyond the schema's bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Bootstrap the bounded V13 FCI-lite discovery surface') and a specific output ('return procedural graph-variant/marked-edge stability'). The jargon distinguishes it from more general causal discovery or bootstrap tools, though it is dense.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives like athena_causal_structure_bootstrap or athena_fci_lite_discover. The phrase 'bounded V13 FCI-lite' implies a particular use case, but there is no when/when-not statement or alternative comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. The word 'Read' implies a non-mutating operation, and mention of 'current CAS version' hints at version-related return details. However, it does not disclose error behavior, permissions, or any side effects beyond being read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), but the description leaves out potential important context such as what exactly is returned, how versioning works, or when to use this vs. other topology tools. It is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the parameter. It doesn't explicitly explain 'topology_id', but the context of reading a topology makes its purpose clear. Still, the description adds no extra detail about the parameter's format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and the resource ('one versioned collective-control topology and its current CAS version'), making the tool's purpose specific. However, it does not explicitly distinguish from sibling topology tools like athena_topology_apply or athena_topology_rollback, though the read nature is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It simply states what the tool does without mentioning when to prefer it over other topology operations or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral transparency burden. It discloses the ranking dimensions but does not state whether the operation is read-only, what constitutes a 'matching' variant, or the output format. The ranking nature suggests a safe read operation, but the transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It begins with the verb 'Rank' and the resource, making it extremely concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, five parameters, and zero parameter documentation, the description is drastically incomplete. It fails to explain the required input 'event', optional filters like 'tags', 'scope', 'threshold', and 'limit', and does not describe the expected output, making correct invocation nearly impossible for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the five parameters (tags, event, limit, scope, threshold). The ranking criteria are not mapped to these parameters, leaving the agent without insight into how to supply inputs correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Rank' and specifies the resource 'matching antibody variants' along with the ranking criteria (semantic match, empirical reliability, status, expiry). This clearly distinguishes it from sibling tools like athena_failure_antibody_match or athena_antibody_evolve, which focus on matching or evolving rather than ranking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for ranking variants, and the ranking criteria give clear context for its use case. However, it does not explicitly state when to use this tool versus alternatives or provide exclusion criteria, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, and it does reveal the method (cross-fitting, influence functions) and inferential outputs (SE, CI). However, it does not explain key behaviors such as required data assumptions, handling of missing data, or limitations of the linear/logistic nuisances. The phrase 'Assumption-scoped' hints at assumptions without specifying them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, with two sentences that pack technical detail. However, 'Assumption-scoped' is vague and contributes little actionable information, so it's not perfect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex causal inference tool with 6 parameters (including nested objects), no output schema, and no annotations, this description is materially incomplete. It omits data format expectations, parameter details, and concrete assumption statements, leaving the agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should explain parameters, but it only indirectly references binary treatment and logistic propensity. It does not clarify what samples, adjustment, assumptions, or propensity_clip mean, nor the structure of the samples objects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a cross-fitted AIPW estimator for binary treatment, specifying the outcome nuisance model (linear), propensity model (logistic), and inference via influence-function SE/CI. This differentiates it from sibling TMLE tools, though the verb 'estimate' is implied rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers only implicit usage constraints: it is for binary treatment and uses specific model forms. It does not say when to prefer AIPW over alternatives like TMLE, nor does it state exclusions or assumptions in concrete terms ('Assumption-scoped' is vague).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It adds a valuable caveat that re-simulation is not performed, suggesting a read-only verification operation. However, it omits side effects, error semantics, and what constitutes a successful or failed verification, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient at two sentences with no redundant content. The first sentence packs in substantial technical detail, which may be dense but each term contributes to specifying the tool's function. The second sentence adds a critical limitation without extending length unnecessarily.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (RAG/HUG-packet/GAP/FIELD/AOR/transport child runs) and lack of an output schema, the description is too terse. It does not explain what the verification returns, how results should be interpreted, or what failure looks like. An agent would struggle to act on the tool's output without additional context, making completeness inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'cycle_id' has no schema description (0% coverage) and is not explained in the tool description. While the description references 'cycle state', it does not clarify how to obtain a cycle_id, what format it should take, or any constraints beyond the schema's minLength. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Verify') targeting concrete resources ('stored cycle state digest', 'deterministic replay/integrity receipts' of persisted child runs). It clearly distinguishes itself from sibling replay tools by explicitly stating that external semantic execution is not re-simulated, making its scope precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit when-not condition ('External semantic execution/test truth is not re-simulated') but no direct when-to-use guidance or named alternatives. It implies use for checking stored integrity, but does not compare with related tools like athena_cycle_state or athena_transport_replay, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It does a good job enumerating what the result cannot do ('cannot deploy, resolve secrets, mutate state, stop/start a writer, or activate traffic'), which conveys a safety-focused, non-destructive operation. Yet it omits what the tool does beyond 'bind', such as persistence, return value, permissions, idempotency, or failure modes, so it meets the minimum but is not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and target. Every clause adds information about inputs or behavioral limits. It is dense and jargon-heavy, but no words are wasted, earning a 4 rather than a 5 due to the high cognitive load.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with no annotations, no output schema, and 0% schema coverage. The description provides only a high-level binding action and a negative list, without explaining what the returned result is, how the hold is represented or verified, or what prerequisites must be satisfied beyond the input types. An agent would struggle to know if the invocation succeeded or how to use the result, making the description incomplete for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It names all four parameters and adds meaningful constraints: the plan must be PLAN_ONLY, the canary witness must be checksum-valid and isolated, quiescence observation is 'supplied', and cutover_authority_ref appears as an 'authority reference'. This goes beyond the bare schema, though it still doesn't describe the structure of the nested objects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Bind') and names the target resource ('ATHENA.CUTOVER.HOLD.1'), distinguishing it from sibling tools like verify_cutover_hold. However, the term 'bind' is somewhat abstract, and the listed input qualifiers ('PLAN_ONLY activation plan', 'checksum-valid isolated canary witness') may not be immediately clear to an unfamiliar agent, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by listing the specific inputs required (plan, canary witness, quiescence observation, authority reference), suggesting this tool is used when such validated artifacts are available to place a cutover on hold. It also hints at a safe, non-deploying purpose via the limitation list. However, there is no explicit 'when to use', no mention of alternatives, and no exclusions, so it only earns a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose the return content and adds a meaningful interpretation caveat ('Surface availability is not activation evidence'), implying the tool only provides manifest data. However, it does not explicitly state that the operation is read-only, has no side effects, or mention any authorization or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and a dense but relevant list of manifest contents, followed by a single important caveat. Every phrase contributes value; there is no redundant or filler language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter retrieval tool, the description offers a detailed inventory of returned content, which is helpful given there is no output schema. However, it does not describe the output format or data structure, and it does not differentiate itself from the closely related athena_runtime_manifest or deployment validation/activation tools, making correct selection harder in a large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters and the schema is empty with 100% coverage, so there is nothing for the description to add. The baseline for zero-parameter tools is 4, and the description appropriately avoids inventing unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Return' as a clear verb and identifies a specific resource (ATHENA.DEPLOYMENT.2), enumerating the laws and components it returns. This signals a manifest retrieval tool and differentiates it from validation or activation tools, though the protocol name is somewhat cryptic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus closely related alternatives like athena_deployment_validate, athena_deployment_activation_plan, or athena_runtime_manifest. The caveat about activation evidence only implicitly warns about misuse but does not name alternative tools or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose a key trait: expansion 'creates work contracts, not semantic results,' and mentions bounding limits. However, it does not cover side effects, permissions, or state changes, leaving gaps in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, compact and front-loaded with the key action. Every clause adds value: the seed source, the constraints, and the output nature. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is too thin. It explains the high-level purpose but not parameter semantics, return structure, or what 'work contracts' entail. The agent may struggle to know exactly what to expect from this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters (actor, result_id, transforms) with zero documentation. The description only hints that 'one witnessed EXTRES payload' likely maps to result_id, but it does not clarify actor or transforms. Since schema coverage is 0%, the description fails to compensate for the lack of parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: using a witnessed EXTRES payload as a seed for next-generation expansion. It also distinguishes the tool by noting that expansion 'creates work contracts, not semantic results,' which contrasts with sibling extraction tools. However, the heavy use of jargon (EXTRES, EXTRUN) without explanation reduces accessibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when you have a witnessed EXTRES payload to expand, with constraints from parent EXTRUN depth and task-per-generation limits. It does not explicitly mention alternatives or 'when not to use,' but the context is specific enough for an agent to select this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The verb 'fetch' implies a read-only operation, and listing the components gives some clarity. However, it doesn't explicitly state that the tool has no side effects, or what happens if the task_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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately states the action and the key data returned. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch-by-ID tool with one parameter, the description is reasonably complete. It states what is fetched and the included components, which covers the return value since no output schema exists. It lacks error-handling details, but that's not critical for such a simple read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It implies that task_id identifies which extraction task to fetch, but it doesn't explicitly describe the parameter's semantics beyond that. The description adds value by explaining what the task includes, which indirectly clarifies the purpose of the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a specific resource (one extraction task) and lists its key components (seed, transform contract, status, result refs). It doesn't explicitly distinguish from sibling tools like athena_extraction_result, but the mention of 'result refs' hints at a different level of detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any conditions, prerequisites, or the relationship to sibling tools such as athena_extraction_run or athena_extraction_result.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden of behavioral disclosure. It states that the tool 'persists' data, but does not explain overwrite/idempotency behavior, permissions, return values, side effects on existing antibodies, or whether the bundle is expected to be complete before registration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence with no wasted words. It front-loads the key verb and resource, then lists the stored components compactly, making efficient use of space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, nested objects, no output schema, and no annotations, the one-sentence description is insufficient. It does not explain return behavior, prerequisites, the meaning of `actor`/`scope`, or how this registration relates to other antibody lifecycle tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates by naming most parameters (signature, trigger, detector, repair, evidence, regression_refs), but it omits `actor` and `scope`. It adds conceptual grouping but lacks detail on nested object structures or relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'persist' and identifies the resource as a 'diagnosed failure' converted into a reusable bundle, clearly distinguishing it from siblings like `athena_failure_antibody_match` or `athena_antibody_evolve`. The enumeration of signature, trigger, detector, repair, evidence, and regression/replay references gives a precise sense of the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a diagnosed failure needs to be persisted, but it provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. With closely related siblings like `athena_failure_antibody_match`, more explicit disambiguation would have been valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It discloses meaningful model behavior—polynomial basis, full covariance, and OOD-dependent interval inflation—but does not state whether the operation is side-effect-free, what the output format is, or how edge cases are handled. This is partial but incomplete disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense, front-loaded sentence followed by a concise exclusion. Every word adds technical value, and there is no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, 0% schema coverage, no annotations, no output schema, and a nested features object, this description is far too sparse. It conveys the model archetype but not enough operational detail for an agent to construct valid inputs, choose correct parameter values, or understand the return contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and no parameter is explicitly explained. The phrase 'OOD-dependent interval inflation' hints at ood_gain and target_coverage, and 'degree-2 polynomial-basis' relates to features, but required fields like regime and arm_id are entirely unaddressed. The description provides only weak semantic clues rather than usable parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a 'Degree-2 polynomial-basis Bayesian prediction' with specific technical traits (full-covariance V5 posterior, OOD-dependent interval inflation), and it explicitly differentiates itself from 'GP/neural universal inference.' This makes the tool's purpose and scope distinct from sibling prediction tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is the negative statement 'Not GP/neural universal inference,' which implies when not to use it but provides no explicit alternatives or when-to-use conditions. The intended use is implied by the model name and technical description, but an agent is not given clear selection criteria among the many sibling prediction tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It contributes substantive invariants: 'UNKNOWN never becomes zero', 'gates are fail-closed', and 'scalar NEXT coexists with Pareto alternatives and explicit budget allocation', plus the 'optionally persist' side effect. It does not describe authentication, rate limits, or the exact persistence destination, but the core safety behavior is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence of roughly 45 words, with the primary action front-loaded and no filler. Every clause contributes meaningful behavioral information, though the semicolon-packed technical phrasing is heavy; overall it is efficient and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a complex nested schema, 9 parameters, no output schema, and no annotations, the description provides rich behavioral invariants but omits parameter semantics and usage guidance. An agent can understand the general operation type but not confidently prepare the inputs for a valid invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the 9-parameter schema, but it does not explain the required `seed` or most parameters. It references domain concepts like evidence, calibration gates, and budget allocation, but never explicitly maps them to `candidates`, `metric_contract`, `persist`, or other schema properties. Some conceptual meaning is added, but an agent cannot confidently construct a correct invocation from this description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Compile and optionally persist AOR.3 decision state', providing a specific verb ('compile') and resource ('AOR.3 decision state'). The persistence option clearly distinguishes it from sibling retrieval tools like athena_orchestration_get and athena_orchestration_replay. Although AOR.3 is not expanded, the action is unambiguous within the tool family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention sibling tools such as athena_orchestration_get/replay/recent/robustness, nor does it state any conditions, prerequisites, or exclusions. The only hint is 'optionally persist', but that is a behavioral detail, not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden, but it does not state whether the operation is read-only or has side effects, what prerequisites exist (e.g., run must already exist), or what failure modes look like. It does disclose that verification targets authority snapshot, routing digest, NEXT, GROW, and Pareto state, but the ambiguity of 'Recompile' plus missing side-effect/read-only clarity is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one focused, front-loaded sentence with no filler or repeated schema information. Every phrase adds detail: the action, the scope (one persisted run), the input nature (frozen inputs), and the verification checks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain the outcome or return format; it does not. It also omits prerequisites (must the run exist?), side effects, and the meaning of the verified state components (NEXT, GROW). While it names specific verification targets, an agent cannot fully infer what the tool returns or what 'verify' produces, making the description incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there is a single required parameter run_id. The description adds the semantic context that the run is a 'persisted AORRUN' and that it is recompiled from frozen inputs, which clarifies that run_id identifies such a run. However, it never explicitly names run_id, ties it to the AORRUN identifier, or explains the expected format, so it only partially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Recompile') and a specific resource ('one persisted AORRUN') and enumerates concrete verification targets (authority snapshot, routing digest, NEXT, GROW, Pareto state). This clearly distinguishes it from sibling tools like athena_orchestration_get/recent, which are retrieval-focused, and from other replay tools that target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Recompile one persisted AORRUN from frozen inputs' implies the tool is for reproducing/verifying a previously persisted orchestration run. However, it provides no explicit when-to-use or when-not-to-use guidance, and does not mention alternatives among the many orchestration/replay/sibling tools, leaving the selection decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It adds a meaningful detail—the calibration uses reliability shrinkage toward the identity predictor—which gives insight into the algorithm. However, it does not reveal whether the operation is read-only, what side effects occur, what data is accessed, or what the return value is. This is partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no fluff. However, it packs multiple technical terms (RGO, reliability shrinkage, identity predictor) into a dense phrasing that may hamper immediate comprehension. Still, it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description leaves major gaps: it does not specify the outcome of calibration, whether it modifies stored data, how downstream observations are accessed, or what 'scope' controls. A one-sentence description is insufficient for a tool with zero schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description names the 'predicted RGO' parameter but provides no format, units, or meaning beyond the name. The 'scope' parameter is entirely unmentioned. The description does not compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('calibrate') with a clear resource ('a new predicted RGO') and a mechanism ('against accumulated downstream observations with reliability shrinkage toward the identity predictor'). This clearly states the tool's function and differentiates it from related tools like athena_rgo_observe or athena_uncertainty_calibrate through the specific calibration approach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is called when a predicted RGO needs calibration using downstream observations, but it does not explicitly state when to use it versus alternatives (e.g., athena_uncertainty_calibrate) or any exclusions. This qualifies as implied usage only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden for disclosing side effects and safety. It reveals that closing a session involves 'public summary telemetry' and optional Git checkpointing with 'expected-head CAS', but it does not state whether the session is deleted, what happens on CAS failure, or any permission requirements. This is insufficient for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action 'Close a session'. Every phrase earns its place, covering the core action, telemetry, and optional Git checkpoint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, nested objects, no output schema, and no annotations. The description does not explain return values, error conditions, or behavior when expected_git_head mismatches. It is too brief to fully guide an agent in using this tool correctly, especially given the CAS mechanism and optional checkpointing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides some context for parameters: 'public summary telemetry' hints at the summary object, and 'expected-head CAS' explains expected_git_head's role. However, it does not explicitly map all parameters (e.g., checkpoint_git relationship to expected_git_head) or provide syntax details. It partially compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Close a session', a specific verb and resource, clearly distinguishing this from sibling tools like athena_session_start. It also adds scope with 'public summary telemetry' and Git brain checkpointing, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'Close a session', which signals when to use it, but it does not explicitly contrast with alternatives or state conditions when not to use it. There is no mention of alternatives or exclusions, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It discloses the statistical shrinkage behavior and empirical basis, but omits potential prerequisites (e.g., minimum row count) and whether the operation is read-only or has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, jargon-dense sentence that front-loads the core action and output. No wasted words, though some terminology may be opaque.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex multivariate statistical tool with no output schema and no annotations, the description is incomplete. It does not describe the exact return structure (e.g., mean vector and covariance matrix orientation), required data prerequisites, or how context influences the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It hints at action_id via 'action-conditioned' and prior_strength via 'shrinkage' but leaves the context object entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: returning a multivariate empirical action-conditioned transition mean/covariance. It uses specific technical language that distinguishes it from sibling tools like transition_predict or transition_observe by emphasizing observed rows and shrinkage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It only implies use with observed transition data ('from V5 observed transition rows') but does not mention sibling tools or when to choose this over prediction/observation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It usefully states two non-obvious behaviors: the tool does not alter AOR authority and it emits a double-count guard if DeltaJ names the same outcome. However, it doesn't cover persistence, return values, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler, starting with the main action verb. The first sentence states the core behavior and the second adds a conditional guard, making every sentence informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter transport tool with no output schema and no annotations, the description lacks critical details: the reward-observation packet's structure, persistence behavior, when to set actor/delta_outcome_ref, and the exact nature of the double-count guard. It needs more to be fully actionable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to observed_rgo, witness_ref, and delta_j (via the double-count guard), and references outcome_ref. However, actor, persist, and delta_outcome_ref are not explained, leaving gaps for a 7-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation—carrying a witnessed RGO outcome into a reward-observation packet—and adds a key qualifier (no AOR authority change) that distinguishes it from likely sibling transport tools. However, 'carry' is somewhat abstract and the description doesn't explicitly compare to adjacent transport tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool via 'without automatically changing...' but gives no explicit when-to-use/when-not-to-use guidance or alternatives. It doesn't mention prerequisites or relationships to other transport tools, though the qualifier provides some contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It mentions the core execution modes, conditional comparison, and optional persistence, which is useful. However, it omits return values, side effects beyond persistence, prerequisites, and error behaviors, leaving gaps for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the core action and packs in mode choices, a conditional step, and an option without wasted words. Every clause contributes significant information, making it highly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no annotations, no output schema), the description is too sparse. It fails to explain key parameter meanings, return values, or usage alternatives, and it does not provide enough detail for an agent to confidently invoke it in varied scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only vaguely maps to parameters: 'subject' hints at subject_id, 'persist' maps to persist, and 'derived coordinate' may relate to dst_chart or output. The required src_chart/dst_chart and optional actor/source_value are left undefined, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Execute' and the specific resource 'newest registered T_ij for a subject', establishing a distinct operation from siblings like athena_register_transform or athena_apply_transform_route. It also lists the method (LOOKUP or DSL) and outcomes (comparison, optional persistence), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context about when the tool applies (newest registered transform, conditional comparison, optional persistence) but does not explicitly state when to use it versus alternatives or any exclusions. The guidance is implied rather than directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full transparency burden. It states a Bayesian update occurs but does not disclose whether the update mutates the belief in-place or returns a new belief, nor does it mention side effects, storage behavior, or requirements like prior existence of the belief context. The description is terse and leaves the tool's operational behavior largely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that places the action verb first and includes the essential qualifiers ('finite,' 'explicit per-model,' 'one actual declared'). It contains no redundant or irrelevant information, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested object, no output schema), the description is too sparse. It does not explain how to construct the likelihoods object, the meaning of context_key in relation to a belief, or what the tool returns. The omission of these details leaves an agent without enough guidance to correctly invoke the tool in a real workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It maps 'likelihoods' to 'explicit per-model likelihoods' and 'outcome' to 'actual declared observation,' but it does not explain the structure or format of the likelihoods object, the role of context_key, or the purpose of optional parameters like actor and evidence_ref. Several parameters remain semantically unexplained, making correct invocation difficult.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Bayes-update') and names a specific resource ('finite belief') while clearly differentiating the operation from sibling tools by requiring 'explicit per-model likelihoods' and 'one actual declared observation.' This distinguishes it from similar belief or observe tools, providing clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you have explicit per-model likelihoods for a finite belief and a single observation. It does not explicitly name alternative tools or exclusions, but the 'explicit per-model likelihoods' and 'finite belief' phrasing gives clear context. However, no direct contrast with sibling tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the disclosure burden. It explicitly states the operation is a read ('Read') and names the contents it returns ('belief distribution and entropy'). It does not cover failure modes, output format, or initialization requirements, but the core behavior is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 11-word sentence that front-loads the verb and resource. It contains no filler or redundant phrasing, and every word adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and one undocumented parameter. While the description states the basic output, it omits crucial invocation details: the meaning of context_key, when to choose this over sibling belief-state tools, and any behavioral edge cases. These are important gaps for correct tool selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single required parameter, context_key, with no description, and schema description coverage is 0%. The description never mentions this parameter, so an agent cannot infer what context_key means, what values are valid, or how it affects the result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and clearly names the resource ('current finite model belief distribution and entropy'). The qualifier 'finite model' helps distinguish it from sibling tools like athena_gaussian_belief_state, and 'current' indicates a state query rather than an observe/register operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to read the current belief state, but it gives no explicit guidance on when to use it versus alternatives, nor any exclusions. Without naming sibling tools or conditions, usage guidance remains only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a meaningful behavioral constraint: token/compute dimensions are accepted only when supplied by an observable client. However, it does not describe write semantics (e.g., idempotency, upsert behavior), error handling, or response behavior, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The main action is front-loaded, and the second sentence adds a necessary constraint without deviating from the topic. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, nested objects, no output schema, and no annotations. The description provides only a brief purpose and one constraint, leaving the agent underinformed about parameter meanings, invocation prerequisites, return values, and edge cases. This is insufficient for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'token/compute dimensions' but does not map this to any of the six parameters. Required parameters run_key and resources are unexplained, and optional parameters (actor, scope, budget, outcome) receive no guidance. Only minimal compensation is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Persist' with a specific resource 'one measured organization/resource budget observation'. This distinguishes it from siblings like athena_budget_schedule (scheduling) and athena_budget_summary (aggregation) by emphasizing a single observation record. The second sentence adds a constraint without obscuring the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for persisting a measured budget observation, and the constraint about token/compute dimensions gives a condition for use. However, it does not explicitly state when to use this vs. related tools like athena_budget_schedule or athena_budget_summary, nor does it provide exclusion criteria or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that identification is conditional on supplied graph/assumptions and uses d-separation, but it does not describe the return format, whether multiple sets are possible, or any side effects. Moderate disclosure for a computation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy. The main action is front-loaded, and every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 7 parameters including nested objects, this brief description is insufficient. It does not explain return values, parameter details, or usage alternatives, leaving significant gaps for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides only high-level context (supplied DAG, assumptions) without detailing parameters like observed_nodes or max_adjustment_size. The word 'minimal' hints at max_adjustment_size but does not explain semantics or syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Search' and resource 'minimal back-door adjustment set in a caller-supplied causal DAG', clearly stating the tool's function. It also differentiates from siblings like athena_causal_identify_extended by emphasizing the minimal constraint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a caller has a causal DAG and wants a minimal adjustment set via d-separation, but does not explicitly state when to choose this over alternatives or provide when-not-to-use exclusions. The context is clear but alternatives are not addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses a key trait: 'without committing topology' implies the tool does not modify topology, adding important context. However, it does not explicitly state whether this is a read-only operation overall, whether it persists any other state, or what side effects may occur, leaving significant gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that starts with the action ('Rank candidate organizations') and packs all key constraints into one breath. There is no redundancy or filler; every phrase adds value, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description should clarify return values and parameter usage. It does neither: it omits any mention of what the tool returns (e.g., ranked list, scores), and it fails to define key terms like 'RGO', 'empirical calibration', or 'bounded learned policy', leaving the agent under-informed for a tool with nested parameters and no schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It explains that 'candidates' refers to candidate organizations and implies ranking criteria, but it says nothing about 'scope' or 'context' parameters, leaving them undefined. The description adds some meaning for one parameter but fails to explain the other two, which is insufficient given zero schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Rank candidate organizations' using specified criteria (base RGO, empirical calibration, bounded learned policy, risk and budget pressure). It also distinguishes itself from sibling tools by explicitly noting 'without committing topology,' which separates it from topology-modifying tools like athena_topology_apply, while still covering simulation aspects that overlap with rollout tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without committing topology' implies a use case where the agent wants to evaluate or rank candidates without making permanent structural changes, but it does not explicitly state when to use this tool versus alternatives such as athena_rollout_simulate or athena_policy_score. There are no explicit exclusions or alternative recommendations, so it is only implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses the decision logic (missing metrics HOLD, thin evidence ROLLBACK, failed gates ROLLBACK), but does not state whether the operation is read-only, what side effects exist, or what permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that fully states the purpose and decision criteria without redundant words. It front-loads the verb and resource and uses a clear three-part structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nested parameters and no output schema, but the description does not explain the expected structure of baseline/canary, how thresholds are used, or what the return value looks like. This leaves significant gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not name or explain the 'baseline', 'canary', or 'thresholds' parameters. It hints at threshold concepts (sample size, window, error rate, restart gates) but does not map them to schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Evaluate supplied external canary observations' and clearly defines the decision outcomes (HOLD/ROLLBACK). This distinguishes it from sibling tools like athena_deployment_assess_quiescence and athena_deployment_validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. Context is implied by the tool name and the decision criteria, but there are no exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses a non-mutation guarantee regarding Y1 canonical claim authority, which is valuable. However, it does not explain other behavioral aspects such as return value, persistence semantics of the V6 record, or any side effects beyond the shadow scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly packed sentence with no filler. It front-loads the action and resource, and every word adds meaning (V6, science-shadow, without mutating Y1 canonical claim authority).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and a domain-specific description that assumes knowledge of V6 and Y1 claim systems. An agent would not know what qualifies as a V6 science-shadow claim, what the return value is, or how the three parameters relate to the registration. The description is not self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no explanation of scope, claim_key, or statement. The parameter names are self-explanatory to a degree, but the description does not compensate for the schema's lack of descriptions, particularly for the optional scope parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (register), the resource (a V6 science-shadow claim record), and specifies a key non-goal (without mutating Y1 canonical claim authority). This distinguishes it from sibling tools like athena_claim_register, which likely handles canonical Y1 claims.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for V6 science-shadow claims and explicitly excludes Y1 canonical claim authority. It does not name an alternative tool, but the exclusion provides clear when-not guidance. Sibling tools include athena_claim_register, which is the likely alternative for canonical claims, though not explicitly referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does add valuable context by stating 'Evidential metadata only' and 'no Y1 canonical rewrite', implying a non-destructive, read-only summarization that avoids altering canonical data. However, it does not disclose the return format, pagination, or whether any side effects exist beyond the exclusion, leaving some ambiguity for a summarize operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence of 12 words. It is front-loaded with the primary action and includes a critical qualifier, with no unnecessary words or repetition. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and two parameters with zero schema descriptions, the description is not complete enough. It leaves key questions unanswered: what exactly does the summary contain, what does 'min_independent_support' mean, and how does the 'science-shadow witness groups' concept relate to the input parameters? The domain-specific jargon is not elaborated, so an agent would struggle to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description offers no explanation of the parameters. While 'claim_id' is self-explanatory, 'min_independent_support' is not clearly defined; it could be a threshold, count, or percentage, and its relationship to 'independent witness groups' remains vague. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Summarize') and a distinct resource ('independent V6 science-shadow witness groups'). It clearly differentiates this tool from siblings like athena_discovery_claim_witness or athena_claim_state by focusing on summarizing groups rather than registering or witnessing claims. The phrase 'Evidential metadata only; no Y1 canonical rewrite' further narrows the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('summarize independent V6 science-shadow witness groups') and an explicit exclusion ('no Y1 canonical rewrite'), which informs the agent not to use this for canonical rewrites. However, it does not name alternative tools or explain when a different tool would be preferred, so it lacks explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses a key behavioral trait: the conflicting history remains in the event ledger, implying the resolution doesn't erase prior events. It also notes the authorized side must be 'already-witnessed'. However, it doesn't mention permissions, idempotency, or whether the other side is marked rejected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single front-loaded sentence with no filler. It conveys the core function and a side effect without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, a nested authority object, no output schema, and no annotations, the description is insufficient. It doesn't explain the meaning of the relation enum (EQUIVALENT/DISTINCT), the required fields in the authority object, what context_id represents, or what happens to the non-authorized side. The one side effect mentioned is valuable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description doesn't mention parameter names beyond implicit references to 'pair' (likely left_id/right_id) and 'authorizing' (likely authority). It doesn't explain context_id, relation enum, the authority object structure, or actor, requiring the agent to infer from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Resolve' with resource 'pair CONFLICT' and clarifies the mechanism 'explicitly authorizing one already-witnessed side', distinguishing it from sibling equivalence tools like athena_equivalence_state/observe/snapshot which focus on observation/state rather than conflict resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a pair conflict exists between left_id and right_id, but does not provide any when-not guidance or mention alternatives such as athena_resolve or other conflict resolution tools. No explicit exclusions or differentiators are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses a critical trait by returning DESIGN_ONLY, implying no execution or side effects. However, it does not state whether the tool mutates state, what the design output contains in detail, or how it handles invalid inputs, leaving significant behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the main verb and directly states the purpose and output type. It contains no redundant or extraneous content, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with 6 parameters, no output schema, and no descriptions in the input schema. The description only provides a high-level overview and a vague 'returns DESIGN_ONLY' tag, without explaining the return format, parameter relationships, or constraints. This is insufficient for an agent to fully understand what the tool returns and how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It maps 'hypothesis priors/likelihoods' to the hypotheses array and mentions cost and risk weights, but it omits sample_size and control_fraction entirely and does not explain the structure of the array items (hypotheses and experiments). The description leaves the agent guessing about key parameters required for invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Rank), the object (binary-outcome experiments), and the criteria (expected information gain under supplied hypothesis priors/likelihoods, cost, risk, feasibility, ethics). It also distinguishes itself from siblings by explicitly returning DESIGN_ONLY, indicating it is for experiment design rather than execution or simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'under supplied hypothesis priors/likelihoods' (i.e., the user must provide hypotheses and experiments), but it does not explicitly state when to use this tool versus alternatives or provide exclusions. It does not reference sibling tools like athena_counterfactual_simulate, so the agent must infer the intended use case from the design-only emphasis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose that outputs become addressable EXTRES results and that completion does not imply output equivalence, which adds value beyond the schema. However, it omits many behavioral aspects such as state changes, failure modes, or mutation side effects, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains zero fluff. It conveys purpose, constraints, and a key caveat efficiently, making it well-structured for quick agent parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a nested witness object, the description should provide more context. It explains the high-level purpose and a caveat, but lacks details on verification semantics, what 'EXTRES result' means, how outputs are handled, and post-conditions. The tool's complexity and extensive sibling set demand a richer description to fully guide invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It vaguely references 'outputs' and 'verified witness' but does not explain task_id, actor, or the structure of the witness object (e.g., what 'ref' means). The conceptual link to a 'planned extraction task' hints at task_id, but the description does not provide sufficient parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Complete one PLANNED extraction task with one or more actual outputs and a verified witness.' This clearly distinguishes it from sibling tools like athena_extraction_plan and athena_extraction_run by emphasizing completion of a planned task. It also adds distinctive detail about outputs becoming EXTRES results, further clarifying its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'PLANNED extraction task' implies this tool is for tasks that already have a plan, but it never explicitly states when to use this tool instead of alternatives like athena_extraction_run or athena_extraction_fail. No exclusions or contrasting conditions are given, so guidance remains implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and succeeds in disclosing key behavioral traits: it only creates PLANNED contracts and never fabricates semantic transform results. This provides a clear safety boundary. However, it omits side effects, permissions, and response details, preventing a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences, with the first stating the core purpose and the second adding a critical boundary. Every word earns its place; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, no output schema, no parameter descriptions), the description is insufficient for operational use. It provides high-level context but does not explain what a PLANNED contract entails, how to set parameters like max_depth or transforms, or what the return value looks like. An agent would struggle to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about the six parameters. With 0% schema coverage, the burden falls entirely on the description, which fails to explain the meaning or role of seed_ref, seed, actor, max_depth, transforms, or max_tasks_per_generation. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' with a resource 'bounded AOR SX.1 extraction run.' It distinguishes itself from siblings like athena_extraction_run by emphasizing that this is a planning step that creates PLANNED work contracts only, clearly separating planning from execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: this tool is for planning an extraction run, not executing it. The phrase 'Planning creates typed PLANNED work contracts only' indicates when to use it, but it does not explicitly mention alternatives like athena_extraction_run for actual execution, nor does it provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses that results are deterministic, that there are exactly seven views, and importantly that ranks/titles/scores are game-state metadata and 'never evidence or authority' — a critical caveat. It doesn't explicitly say the operation is read-only, but 'Return' implies no side effects; still, it doesn't mention potential errors or freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the action and key resource, and the second adds an essential caveat. Every word contributes meaning, even though the first sentence uses domain jargon (P3+, scoped).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description must explain more. It states what the tool returns but does not describe what the seven views are, how the optional parameters affect them, or any return structure details. The absence of parameter semantics is a significant gap for a tool that accepts three configurable options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has three optional parameters (limit, remote, shared_remote_mode) with 0% schema description coverage. The description provides zero explanation of these parameters, failing to compensate for the low coverage. It does not clarify what 'remote' or 'shared_remote_mode' control, how they affect the seven views, or what 'limit' applies to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with the specific verb 'Return' and precisely identifies the resource: seven deterministic leaderboard views over P3+ scoped verified Impossible Challenge completions. The detail about 'game-state metadata' differentiates it from sibling leaderboard-like tools (e.g., athena_hall_of_immortals) by establishing a unique scope and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool — whenever you need leaderboard views for P3+ verified completions — but provides no explicit guidance on when not to use it or which alternatives might be preferable. There is no mention of exclusions or competing tools, so the usage context is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral transparency. It adds meaningful context by stating that the output separates within-model and between-model variance, and that averaging is over a finite posterior. However, it does not disclose prerequisites, side effects, or return format, leaving a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It packs a precise definition into 14 words, so it earns a high score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, nested objects, no output schema) and the complete absence of annotations, the description alone is insufficient. It gives a high-level purpose but leaves parameter meanings, return values, and usage prerequisites unexplained. Thus it falls short of a complete tool definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explicit mapping to the 4 parameters (context_key, features, candidates, include_observation_noise). The reference to 'GP prediction' could relate to features, but no semantic details are given, so the description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Bayesian-model-average' and identifies the resource as 'a GP prediction across the finite hyperparameter posterior.' It clearly distinguishes from siblings like athena_gp_predict or athena_gp_sparse_predict by specifying the BMA and finite posterior aspect. The variance separation detail adds further specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for use when a finite hyperparameter posterior exists. It does not explicitly name alternatives or exclusion criteria, but the scenario is clear. Sibling tools like athena_gp_predict are not referenced, which would have made the guidance more explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly discloses 'Read-only' and 'deterministic', which are key behavioral traits. The deterministic Halton QMC detail also hints at reproducibility. However, it does not mention what the returned output represents (e.g., particles, approximation object) or any edge-case behavior, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the primary purpose and methodology, followed by a brief safety note ('Read-only'). Every word earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of nested bounds, a required context_key, and no output schema, the description is too terse. It does not specify the expected format for bounds, what the output is (e.g., posterior samples or a fitted object), or the purpose of context_key. An agent would struggle to invoke this tool correctly without additional external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not compensate. It hints that 'bounds' is a positive box and that 'samples' corresponds to particles, but does not explain the structure of the bounds object, the role of seed in a deterministic method, or the meaning of context_key, which is the only required parameter. This leaves key parameters underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action: approximate a GP hyperparameter posterior using specific methodology (Halton QMC particles) within a defined scope (continuous log-uniform, positive box). This is a specific verb+resource combination that distinguishes it from sibling tools like athena_gp_hyperfit or athena_gp_hyperposterior by emphasizing approximation and deterministic QMC.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to choose this tool over alternatives such as athena_gp_hyperposterior or athena_gp_hyperfit. The description implies approximation via QMC but doesn't state criteria like 'when an exact posterior is too expensive' or contrast with exact methods. It only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds a behavioral guarantee ('without fabricating output') and indicates a verification requirement ('witnessed'), but it does not disclose side effects, idempotency, or what happens on success/failure. This is some value beyond the schema, but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action and adds a meaningful constraint. Every word contributes value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with 4 parameters (nested object), no output schema, and no annotations, a one-sentence description is insufficient. The agent is left without terms like 'PLANNED HUGINV', what constitutes a failure, how to structure the witness object, or what the tool returns. The sibling tool list provides some context but does not fill these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it only implicitly references the 'witness' parameter via 'witnessed' and gives no meaning for invocation_id, reason, actor, or the witness.ref field. The agent cannot infer parameter semantics from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'record' and identifies the resource ('witnessed executor failure for PLANNED HUGINV'), clearly distinguishing this from sibling tools like athena_hug_complete or athena_hug_plan. The addition of 'without fabricating output' further sharpens the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'witnessed executor failure' implies the tool should be used when a failure occurs, rather than success, but no explicit when-to-use or when-not-to-use guidance is given. It does not name alternative tools or exclusions, so the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It discloses that the tool is PLAN_ONLY and never self-training, indicating no model updates or learning side effects. However, it does not mention what the tool returns, whether it modifies state, or any error-prone conditions, leaving significant behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The main purpose is front-loaded, and the behavioral constraint is concise. Every word earns its place, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex planning tool with no output schema, no annotations, and a large sibling set, this description is incomplete. It fails to explain what the output represents (e.g., a plan sequence or a value), the practical meaning of receding-horizon, or the roles of the unexplained parameters, leaving the agent without crucial information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially maps 'caller-supplied actions' to the actions parameter and 'receding-horizon' to the horizon parameter, and 'risk-adjusted' hints at risk_aversion. However, discount, beam_width, prior_strength, and initial_context remain completely unexplained, and with 7 parameters, this is insufficient for agent understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('planning') and resource ('caller-supplied actions using the learned multivariate transition surface'), with qualifiers ('receding-horizon', 'risk-adjusted') that distinguish it from other planning tools like collective_plan or dual_control_plan. The 'PLAN_ONLY' constraint adds further specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for risk-adjusted sequential planning over caller-supplied actions, but it does not explicitly compare with alternative planning tools or state when not to use it. The 'never self-training' phrase provides a hint that this tool is not for learning tasks, but no exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context by stating 'without widening execution authority' and listing descriptor categories (semantic capability, effect, authority, freshness, preconditions, replay, rollback). However, with no annotations, it still leaves gaps about output format, error conditions, and whether the operation is purely read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the core purpose ('Return OPERATIONAL_BASIS_V1') and packs additional semantic detail without redundancy. Every phrase contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter retrieval tool with no output schema, the description adequately explains what is returned and the dimensions covered. It lacks an example or explicit mention of return structure, but this is a minor gap for such a simple interface.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. The description appropriately focuses on the output rather than inputs, meeting the baseline for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return OPERATIONAL_BASIS_V1 derived from the actually registered current prompt/control-plane MCP surface', identifying a specific verb and resource. It distinguishes itself from siblings by focusing on the operational basis of the registered MCP surface, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It implies usage for inspecting the current operational basis but does not state exclusions or contrast with similar tools like athena_surface_audit or athena_topology_get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses boundedness, reliance on Gaussian conditional independences, conservative collider propagation, and the fact it is not full FCI/RFCI. However, it does not describe output format, whether it mutates state, or potential failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences convey the core function, method, and limitation without fluff. The description is front-loaded with the primary action and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the clear purpose, the description is incomplete for an agent: there is no output schema, no annotations, no return-value explanation, and the four parameters are undocumented. For a non-trivial causal discovery operation, this leaves significant gaps in using the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meanings. It indirectly references 'samples' via 'observed Gaussian conditional independences' and hints at boundedness with 'bounded', but it does not explain alpha, variables, or max_conditioning values. This is insufficient for a 4-parameter tool with no schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Build') and names the exact resource ('a bounded PAG-like circle/arrow/tail candidate') derived from a defined method (Gaussian conditional independences and conservative collider propagation). It explicitly distinguishes itself from full FCI/RFCI, clarifying scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear exclusion ('Not full FCI/RFCI') but does not explicitly state when to use this tool over sibling causal discovery tools like athena_causal_skeleton_discover or athena_pc_stable_discover. The intended use is implied rather than directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the field is 'persistent', indicating a read from stored state, and 'Return' suggests a non-mutating operation. However, it does not explicitly state side effects (none expected), return format, or potential costs like large data volumes. It gives some context but not full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words, front-loaded with the action and resource. It is concise and avoids any unnecessary fluff or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a query with optional parameters and no output schema, so the description should at least hint at the return shape or parameter semantics. It only states what the field is grouped by, but not the output format, default behavior, or how parameters affect results. This leaves significant gaps for autonomous selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention 'limit' or 'min_score' at all. The parameter names provide some clue (limit, min_score), but the description does not clarify what 'min_score' filters on (e.g., pheromone intensity at which scale?) or how filtering interacts with the grouped result. The description fails to compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Return' with a clearly identified resource ('persistent multiscale pheromone field') and specifies the grouping dimensions ('by token/artifact/module/domain/system scale'). It distinguishes from the sibling tool 'athena_pheromone_field' by emphasizing 'multiscale', clarifying this is the multi-scale variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: an agent would use this tool when it needs the multiscale pheromone field. However, there is no explicit guidance on when to choose this over the similar 'athena_pheromone_field' (single-scale) or other pheromone tools, nor any exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the rollback is implemented as a new versioned transaction and that history is preserved, which are important behavioral traits. However, it does not explain the optimistic concurrency mechanism implied by 'expected_version', side effects, or reversibility. This is adequate but has clear gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 13 words, concise and front-loaded. It efficiently conveys the core purpose and a critical behavioral caveat without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4 parameters, no output schema, and no annotations, the description is too thin. It does not mention expected_version's role, what the tool returns, or error behavior. For a mutation tool with this complexity, the description leaves critical context unaddressed, resulting in a 2.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the parameters (txid, actor, scope, expected_version). The term 'transaction' hints that txid refers to the transaction to roll back, but expected_version, actor, and scope are left entirely unexplained. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Rollback'), the object ('one organization-policy transaction'), and the key behavior ('as a new versioned transaction; history is preserved'). This distinguishes it from sibling tools like athena_policy_update (which updates policy) and athena_topology_rollback (which rolls back topology).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need to roll back an organization-policy transaction. However, it does not explicitly state when not to use it or mention alternatives like athena_policy_update, so it lacks explicit exclusions. Clear context but no exclusions earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the empirical, non-guaranteed nature and the OOD inflation behavior, but does not mention side effects, persistence, permissions, or output structure. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences front-load the core action and then add a crucial caveat. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A 7-parameter tool with nested objects and no output schema needs more explanation to be safely invoked. This description lacks parameter constraints, return semantics, and usage scenarios, making it incomplete for an agent despite the clear summary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the seven parameters. The phrases 'V5 observations' and 'OOD pressure' loosely map to features/regime/ood_gain, but required fields like arm_id, scope, coverage, and min_scores receive no semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Build' and identifies a distinct resource ('empirical prequential residual band') plus scope ('retained pre-update V5 observations', 'current OOD pressure'). The final sentence explicitly distances it from conformal guarantees, which helps differentiate it from sibling uncertainty/calibration tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use under current OOD pressure with retained V5 data, and warns it is not a distribution-free conformal guarantee. However, it does not provide explicit when-to-use vs alternatives or name a specific sibling tool, so guidance remains somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only mentions 'CAS-activate' and 'scope-limited overlay' without explaining side effects, prerequisites like the git head, reversibility, or what changes state. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and key constraints. It is concise with no unnecessary words, earning a top score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, nested objects, no output schema, and no annotations, this sparse description is inadequate. It omits how scope is defined, what the witness object requires, the role of expected_git_head, and what successful activation returns or changes, making it incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any parameter names or meanings (e.g., candidate_ref, scope, witness). It provides no parameter-level semantics beyond the tool's overall purpose, leaving the agent to infer from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('CAS-activate') with a clear target ('TESTED prompt candidate') and specifies the mode ('scope-limited overlay') and condition ('after an observed PASS witness'). This distinguishes it from related prompt tools by emphasizing the tested and witnessed prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use: after a PASS witness and for a TESTED candidate. However, it does not explicitly mention alternatives or when-not-to-use scenarios, so it lacks the exclusionary guidance needed for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that this is a persisting (write) operation and adds a validation rule regarding observed/verdict, but it does not mention idempotency, duplicate behavior, whether candidate_ref must already exist, required permissions, or what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the operation and includes a meaningful constraint. Every word earns its place, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter persist operation with nested objects, no output schema, and no annotations, this description is too sparse. It does not explain return behavior, required relationships between parameters, the meaning of 'baseline/candidate', or the tool's place in the prompt experiment workflow relative to sibling tools, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining the 7 parameters. It only clarifies the relationship between observed and verdict ('observed PASS' requires execution), leaving candidate_ref, expected_git_head, observations, evidence_refs, and actor without semantic explanation beyond their names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Persist') and a specific resource ('baseline/candidate prompt experiment record'), clearly indicating it saves a prompt experiment record. The constraint about unexecuted designs adds scope and distinguishes it from sibling prompt-lifecycle tools like athena_prompt_propose or athena_prompt_activate, which focus on other stages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when recording the outcome of a prompt experiment, and it explicitly warns that unexecuted designs cannot be recorded as observed PASS. However, it does not name alternatives or explain when to choose this tool over related experiment/prompt tools, leaving the guidance only implicit beyond the validity constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool mutates learned geometry and adds a conceptual caveat about routing context vs. semantic identity. It does not mention side effects, persistence, permissions, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and inputs, and the second sentence is a meaningful caveat rather than filler. It is appropriately sized for the stated purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters including a nested object, no output schema, and no annotations. The description only covers the required inputs and one high-level caveat, leaving optional parameters, input structures, side effects, and return behavior undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates only for 'signals' and 'reward' by labeling them as observable/measured. The remaining parameters (domain, weight, cluster_id) are completely unexplained, leaving a significant semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Update') on a specific resource ('learned task-regime centroid') and names the inputs ('observable signals and measured reward'). It also distinguishes the tool from semantically-oriented siblings by adding 'Learned geometry is routing context, not semantic identity.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: the tool should be used when you have observable signals and measured reward to update a learned centroid. However, it does not explicitly mention when not to use it or identify sibling alternatives like athena_regime_geometry_resolve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are given, so the description carries the burden. It discloses the fresh-sync operation and that the delta is read-only and content-addressed, but omits side effects of the sync, permission needs, or return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. The distinction from successor task routing is efficiently stated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a clear purpose, the tool has 3 undocumented parameters, no output schema, and no annotations. The description lacks details on alternatives like athena_rehydration_handoff_resume and what the delta contains, leaving an agent under-prepared for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation for the three parameters (remote, loop_id, shared_remote_mode). An agent cannot know how to set these parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'derive' with resource 'read-only, content-addressed handoff delta describing what a successor agent must rehydrate.' Explicitly states it is distinct from successor task routing, helping disambiguate from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions the process (fresh-sync then derive) and provides an exclusion by saying 'Distinct from successor task routing.' However, it does not name alternative tools like athena_rehydration_handoff_resume or detail when to use this over them, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Return' implies a read-only status operation and names the outputs, but it does not explicitly state that no mutation occurs, nor does it mention any permissions, failure modes, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with front-loaded action and no wasted words. Every phrase contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and low complexity, the description is reasonably complete: it names the three categories of returned information. However, terms like 'component versions' and 'schema-ledger version' are vague, and the absence of an output schema means the exact shape of the response is not fully conveyed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds value by naming what is returned, which is sufficient since there is nothing to explain about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and clearly identifies the resource (runtime DB schema-ledger) and the exact items returned. However, it does not explicitly distinguish this from sibling tools like athena_schema_verify or athena_runtime_manifest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as athena_schema_verify or athena_runtime_manifest. No exclusions, prerequisites, or recommended context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses methodological behavioral traits (AIPW augmentation, history preservation, assumption scope) but does not mention operational side effects, output shape, validation behavior, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, followed by a scope warning. Every word serves a purpose and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no annotations, no output schema, and 0% parameter coverage, the description is insufficient. It does not explain input structures, assumption object requirements, output format, or how it differs from the crossfit sibling, leaving the agent under-informed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. The description provides only high-level hints (two-timepoint, policies) but does not define or elaborate on any of the nine parameters such as 'samples', 'policies', 'assumptions', or 'propensity_clip'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair: 'Estimate deterministic two-timepoint dynamic-policy value' with methodological qualifiers ('sequential AIPW augmentation', 'explicit history preservation'). This distinguishes it from siblings such as the crossfit variant and more general longitudinal tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an important caveat: 'Assumption-scoped; not a general longitudinal causal theorem.' This implies when it should be used (when assumptions hold) and warns against general use, but it does not explicitly name alternatives or provide concrete selection criteria versus the crossfit sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. The caveat 'Missing features are not synthesized' is a meaningful behavioral trait that adds clarity. However, it does not mention side effects, determinism, or other expectations like what happens if prior_strength is missing, leaving partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler, front-loaded with the primary purpose. The additional caveat about missing features is concise and adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a complex nested 'context' object, the description leaves many gaps: the expected context structure, the role of prior_strength, and the return format are all unspecified. The tool would be difficult to invoke correctly without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides only a vague hint about context features through 'missing features are not synthesized.' It does not explain the required structure of 'context', the purpose of 'action_id', or the meaning/effect of 'prior_strength', so parameter semantics are largely uncompensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (predict) and the object (context deltas/uncertainty) from a specified source (observed action transitions). It distinguishes itself from observation tools by using 'predict,' making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The phrase 'from observed action transitions' implies it should be used after such observations exist, but no exclusions or named alternatives are given, making the usage context merely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It conveys important execution traits: isolated Python mode, sanitized environment, timeout, network-socket monkeypatch, and POSIX resource caps when available. It also includes an honest caveat that it is not OS-hermetic, which sets accurate expectations. However, it does not state what the tool returns or whether side effects might occur beyond the described isolation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that puts the core action upfront and uses every word to add value. The final caveat 'Not claimed OS-hermetic' is a concise, useful limitation statement. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is behaviorally rich but incomplete in key areas. It does not explain what a 'witness' is, how to populate the required regression_ref parameter, or what the tool returns. Given there are no annotations and no output schema, the agent must rely on bare parameter names to infer inputs and has no guidance on outputs. This makes the description only partially complete for a tool with five parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not map any of the five parameters to their meanings. The schema provides only names and types, e.g., regression_ref, cpu_s, memory_mb, timeout_s, and actor, but no descriptions. The description generically mentions 'timeout' and 'resource caps' but does not explicitly tie them to specific parameters. This fails to compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: executing one repository-owned unittest witness. It specifies the verb 'execute' and the resource 'repository-owned unittest witness', and adds scoping details like isolated Python mode and sanitized environment. However, it does not explicitly distinguish itself from sibling tools such as athena_antibody_execute_regressions, which may also execute tests, so it falls 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: this tool is for executing a specific unittest witness. However, the description provides no explicit guidance on when to use this versus other tools, nor does it mention any exclusions or prerequisites. It is clear enough to infer a use case but lacks explicit decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action (recording) but does not disclose side effects, prerequisites (e.g., whether the antibody must be pre-registered), idempotency, error behavior, or what the tool does on duplicate records. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys the tool's purpose and enumerates the outcome types. No redundant information or filler words are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and sparse parameter descriptions, the description is insufficient for effective use. It does not explain what a 'known failure antibody' is, what the function returns, how to identify the antibody, or whether prior registration is needed. The existence of sibling tools like athena_failure_antibody_register hints at a workflow, but this is not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds meaning for two parameters: 'outcome' (listing valid values) and 'antibody_id' (implied by 'known failure antibody'). However, the 'actor' parameter is not explained at all, leaving it ambiguous. The description partially compensates for the lack of schema descriptions but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Record') and resource ('outcome for a known failure antibody'), and enumerates the exact types of outcomes (success, failure, false positive, regression pass, regression failure). This distinguishes it from siblings like athena_failure_antibody_register or athena_antibody_evolve, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context: it is for recording outcomes specifically for 'known failure antibodies.' It does not explicitly name alternatives or exclusions, but the phrase 'known failure antibody' implies it should be used when such an antibody exists, effectively distinguishing it from registration or selection tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses substantial behavioral detail: V2 additive fields, 20 source-backed adapters, 20 primary sources, 15 conditioned quantitative claims, bounded expansions, operator phylogeny, and optional evidence packets. It also notes that user seed numbers remain distinct from verified empirical constants, which is a semantic nuance not obvious from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The main purpose is front-loaded, and all details serve a purpose. The structure is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description thoroughly explains the catalog contents, which is the core of the tool. However, it omits parameter meanings, usage context, and doesn't fully specify return format or pagination. Given the lack of an output schema and no parameter explanations, the description is only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It never mentions include_atlas and only alludes to 'optional evidence packets' for include_evidence. It fails to clarify what the toggles do or their effect on the returned catalog, leaving the agent without enough information to decide whether to set them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Return the stable 12-archetype/14-seed BNMK catalog,' clearly specifying the verb and resource. It distinguishes from bionano siblings (assembly, compile, transfer) by focusing on the static catalog rather than operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when/when-not guidance is provided. It does not mention alternatives or usage context. The only implication is that it is a retrieval tool, but there is no comparison to sibling bionano tools, leaving the agent without clear selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly indicates this is a fetch operation (read-only behavior implied) and mentions the return includes payload and provenance. However, it does not describe error behavior, prerequisites, or response format, which are gaps for a tool where no other structured information exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It starts with the verb 'Fetch' and delivers the core purpose efficiently, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter schema, the description is adequate but lacks details about the result payload structure, provenance format, and error handling. Since there is no output schema, a bit more detail about the return value would improve completeness, but the tool's simplicity keeps this from being a major deficiency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, result_id, with 0% description coverage. The description does not explicitly map the parameter or provide any additional meaning beyond the schema; although the parameter name is self-descriptive, the description fails to capitalize on the opportunity to clarify that result_id identifies which extraction result to fetch.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches one witnessed extraction result payload and provenance, with a specific verb and resource. It distinguishes itself from sibling extraction tools like athena_extraction_expand_result by focusing on fetching a single result rather than expanding or planning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: an agent would use this when it has a result_id from an extraction workflow. However, there is no explicit guidance on when to prefer this over alternatives or when not to use it, leaving some ambiguity among the many extraction-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It does this reasonably well by using 'Fetch' (implying a read operation) and by explicitly listing the contents of the returned FIELDRUN ('frozen module inputs, candidates, metric states, provenance edges and digest'). This gives the agent a clear expectation of the response shape. However, it does not disclose error behavior (e.g., what happens if run_id is not found) or whether the data is historical/point-in-time, which would add further transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb 'Fetch' and immediately states the object ('one persisted FIELDRUN'). It then efficiently lists the key components without extra fluff. Every word earns its place, making it concise and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter and no output schema, the description is largely complete: it states what is fetched and what is included in the result. The terms 'FIELDRUN', 'frozen module inputs', and 'provenance edges' are domain-specific but appear consistently across sibling tools, so an agent familiar with the system will understand. The main gap is the lack of usage context (when to use this vs. alternatives) and any note about the absence of an output schema. Overall, the coverage is adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the single parameter run_id, and schema description coverage is 0%. The description partially compensates by implying that run_id identifies a 'persisted FIELDRUN', which clarifies the parameter's purpose. However, it does not explain how to obtain a valid run_id, its format, or its lifecycle, leaving some ambiguity. The description adds some meaning but not full compensation for the schema's silence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and clearly identifies the resource being fetched: 'one persisted FIELDRUN'. It also enumerates the specific components included (frozen module inputs, candidates, metric states, provenance edges, digest), which helps distinguish it from other tools that might only retrieve a summary or a list. However, it does not explicitly contrast itself with sibling tools like field_recent or field_replay, so it doesn't fully differentiate within the family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios where fetching a full FIELDRUN with provenance is appropriate, nor does it note any prerequisites (e.g., run_id must come from a recent list). This is a clear gap, especially given the large number of sibling tools with similar fetch/recent/replay patterns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing that it returns posterior mean/variance, uses exact fixed-hyperparameter RBF GP, and never self-trains. This goes beyond the schema and gives important behavioral context. It lacks details on prerequisites or error states, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the core function, and every word contributes value. The second sentence adds a critical behavioral trait without redundancy. This is ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential purpose and a key behavioral trait, but with no output schema and no parameter explanations, it leaves gaps. It doesn't clarify what 'context_key' refers to (e.g., a registered GP model), how to construct 'features', or what the return format looks like beyond mean/variance. For a prediction tool with three parameters, this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters, but it doesn't. It never mentions what 'features', 'context_key', or 'include_observation_noise' mean or how they affect the prediction. The only hint is 'for one query', which vaguely aligns with 'features', but no actual parameter semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Return exact fixed-hyperparameter RBF GP posterior mean/variance for one query.' This uses a strong verb, specifies the resource (GP posterior), and narrows scope (exact, fixed-hyperparameter, RBF, one query). It distinguishes from siblings like sparse or hyperfitting GP tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (exact GP prediction with fixed hyperparameters) and explicitly says it never self-trains, which hints against using it for hyperparameter fitting. However, it does not name alternative tools or provide explicit when-not-to-use conditions, leaving the agent to infer based on sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does state that the tool is read-only, which is a key safety trait, but it does not describe the return format, error behavior, or any side effects, leaving significant gaps for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with key information front-loaded. Every word earns its place; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters with nested objects and no output schema, yet the description does not explain the return value, provide examples, or detail the belief composition. For a complex tool, this is inadequate for an agent to invoke it correctly without further assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It maps parameters to concepts: axes (with a 2..5 bound), compatibility multipliers, and optional state likelihoods, adding meaning beyond the bare schema names. However, it does not clarify the structure of nested objects or how to construct them, so the enrichment is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: composing a bounded finite joint science-twin belief with specific inputs (factor axes, compatibility multipliers, optional state likelihoods). It also explicitly distinguishes it from a universal joint posterior, which helps differentiate it from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when constructing a bounded joint belief across 2..5 axes and notes it is not a universal joint posterior, but it does not explicitly state when to prefer this tool over alternatives or provide exclusions beyond that. No alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose the algorithmic mechanism ('using latent-only internal directed paths/common latent ancestors') and the output type ('restricted observed ADMG'), which adds useful context. However, it does not mention side effects, return format, or whether the input is mutated, leaving behavioral traits partially undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and the final 'Not data discovery' is a useful clarification. Every word earns its place; there is no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the operation and the absence of an output schema, the description gives a precise definition of the transformation but does not describe the return value structure, error conditions, or edge cases. It is adequate for a domain expert but not fully complete for an automated agent without prior knowledge of ADMG projection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explicitly map parameters. It implies meanings (causal DAG → edges, explicit latent nodes → latent_nodes, observed ADMG → observed_nodes) but does not provide detailed semantics or format guidance. The description adds only implicit meaning, not enough to compensate for the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Project a supplied causal DAG with explicit latent nodes into a restricted observed ADMG') with a clear resource and outcome. It also distinguishes itself from data discovery methods by explicitly stating 'Not data discovery,' which differentiates it from sibling tools like athena_pag_candidate_discover or athena_fci_lite_discover that perform data-driven discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context of when to use the tool (when you have a causal DAG with latent nodes and need an observed ADMG) but does not explicitly name alternatives or exclusions beyond 'Not data discovery.' It lacks explicit guidance on when NOT to use this tool in favor of another, so it gives partial guidance but not full usage clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses deterministic behavior and symbolic-only boundaries, which are useful. However, it does not state whether the tool is read-only, modifies state, or describe error/edge-case behavior, leaving important operational traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the acronym and core action. Every phrase contributes: deterministic selection, codebook source, sample/seed dependency, and the symbolic-only caveat. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex input schema (nested codebook objects, enums) and no output schema or annotations, yet the description only covers purpose and boundaries. It omits the output format, use_case behavior, query semantics, and codebook construction guidance, leaving an agent under-equipped to invoke the tool correctly in varied contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does mention 'explicit sample/seed' and 'caller-supplied codebook', covering the key inputs. But it leaves 'query' and 'use_case' unexplained—both are in the schema but their purpose and interaction with the decode behavior are not clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific operation ('deterministically select/decode'), a clear resource ('caller-supplied codebook'), and the governing inputs ('explicit sample/seed'). It also distinguishes itself from siblings by emphasizing 'symbolic-only' and 'no factual prediction,' though the unexplained 'OSD' acronym adds minor ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use when deterministically selecting/decoding a symbolic codebook from explicit sample/seed inputs. It also gives an explicit exclusion ('no factual prediction or high-stakes authority'), which helps the agent avoid misuse. However, no alternative tools are named, and there is no explicit 'when not to use' beyond the high-stakes caveat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It does disclose meaningful behavioral context: the board is Git-backed, reads should precede expensive work, and writes require a verified remote frontier. However, it does not describe per-action side effects, return values, locking/lease behavior, or failure semantics, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long and every sentence earns its place: the first defines the tool, the second gives action-specific usage guidance, and the third states a critical write precondition. It is dense but not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (23 parameters, 7 actions, no output schema), this description is not complete enough for correct invocation. It provides high-level coordination semantics but omits per-action parameter requirements, optional field purposes, return structures, and detailed remote-frontier behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 23 parameters with 0% description coverage, and the description only hints at a few of them (present, join, REPLICA, frontier). It does not explain the many optional fields such as work_key, lease_seconds, targets, reply_to, or message_kind, so it adds minimal semantic value for the parameter-heavy tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a shared Git message board and enumerates its coordination purposes: presence, work claims, duplicate-work prevention, collaboration, heartbeats, acknowledgements, and release/handoff. This is specific and useful, but it does not explicitly distinguish the tool from potentially similar siblings like athena_godboard or athena_party_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Read before expensive shared work; use present to claim a lane, join to collaborate on an existing lane, or REPLICA only for deliberate independent replication.' It also states a clear precondition for writes: 'Writes always require a freshly verified shared remote frontier.' This is strong, actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly discloses that the tool 'never mutates global XP authority' and that legacy calls with missing coordinates 'remain parseable but HOLD.' These are valuable behavioral insights beyond the basic record/calculate action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a distinct purpose: stating the action, outlining award requirements/hold behavior, and providing a safety guarantee. It is concise and well-structured, though dense with domain jargon.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's complexity (9 params, no output schema, no annotations), the description leaves many gaps. It does not explain the return value, how to structure 'results' entries, what 'current frozen claims' concretely means, or how parameters like 'remote' and 'witness_ref' are used. The cryptic jargon and missing operational details make the description incomplete for context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter explanations. It mentions 'source_xp_ref' and 'ACKed typed result events' which map loosely to schema fields, but most parameters (observation_id, party_id, observer, base_xp, results, witness_ref, remote) are left unexplained. The description provides insufficient meaning beyond the schema's names/types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records a 'witnessed multi-goal party outcome' and calculates a 'receipt-gated coordination XP bonus candidate.' This specific verb+resource combination distinguishes it from siblings like athena_party_result or athena_party_state, which likely handle different aspects of party processing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about the requirements for an award (frozen claims, ACKed events, unused source_xp_ref) and notes legacy calls HOLD, but it does not explicitly name alternative tools or state when to prefer this tool over siblings. Usage is implied rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description's 'Read' indicates a non-mutating operation and the content list outlines expected return data. However, it does not disclose potential side effects, error behavior if called without a fresh sync, permissions needed, or whether the call modifies any state (e.g., marking evidence as read).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the action and efficiently lists the included data. Every word adds value with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with no output schema, the description gives a useful high-level overview and content list, but it omits parameter semantics and return shape, leaving the agent unable to reliably invoke the tool. The sync precondition is mentioned, but edge cases and prerequisites are not elaborated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema-description coverage is 0%, and the description does not explain any of the three parameters. 'party_id' is only implicit from 'Read one party', while 'remote' and 'shared_remote_mode' are entirely undefined, leaving the agent without guidance on how to set them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Read one party') and scope, listing concrete data categories (members, board presence, acknowledged communication evidence, Big-3 score, reward receipts). The phrase 'after a fresh shared-board sync' adds a specific condition that distinguishes this state-reading tool from sibling operations like list or observe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear precondition: 'after a fresh shared-board sync', guiding when this tool is appropriate. It does not explicitly name alternatives or exclusions, but the stated context is enough to infer intended usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing side effects. It clearly states 'without mutating JSPACE,' which is an important safety behavior. However, it uses 'journal' without explaining what journaling entails (e.g., writes to a log, requires permissions) and does not describe behavior when version/head checks fail. This partial disclosure warrants a mid-range score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence with no redundant filler. Every phrase contributes meaning: the action, the resource, the validation targets, and the side-effect-free guarantee. It is appropriately front-loaded and efficient for its complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It does not describe what the tool returns, what an error condition looks like, or how 'journaling' manifests. It also lacks context on prerequisites (e.g., existing topology) and relationship to sibling projection tools. The single sentence covers purpose but not operational details, which is a significant gap for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It maps the phrase 'topology/semantic/Git heads' to the expected_topology_version, expected_semantic_eid, and expected_git_head parameters, providing useful grouping. However, it does not explain the meaning of 'topology_id' or 'actor', nor clarify accepted formats (e.g., whether expected_git_head is a full hash). The description adds some value but leaves several parameters underdefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: preparing and journaling a topology-to-JSPACE projection plan. It specifies the resource ('projection plan') and the key constraint ('without mutating JSPACE'), which distinguishes it from sibling tools that likely execute or mutate. The verb 'prepare and journal' is specific and action-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a dry-run or validation use case by mentioning 'against explicit topology/semantic/Git heads' and 'without mutating JSPACE,' but it does not explicitly state when to use this tool versus alternatives like athena_topology_project_jspace or athena_projection_status. There is no named alternative or 'use this when' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses the key behavioral trait of not expanding full snapshots, and 'List' implies read-only, but it does not mention side effects, required permissions, or the meaning of 'recent'. Basic transparency is present but limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded. It communicates the core action and a key differentiator without unnecessary words or restating the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description explains what it does but leaves ambiguity around 'recent' (time window?) and what a 'reconstruction receipt' is. The 'Ω snapshots' reference is cryptic. Given the context, it is minimally sufficient but not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter, 'limit', with schema definition (integer, min 1, max 500) but no description. Schema description coverage is 0%. The tool description does not mention 'limit' at all, so the agent must guess that it controls the number of receipts returned. This does not compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'recent reconstruction receipts'. The qualifier 'without expanding full Ω snapshots' distinguishes this from related tools like athena_reconstruction_get or athena_reconstruction_verify, making the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without expanding full Ω snapshots' implies when this tool is appropriate (lightweight listing) but does not explicitly mention alternatives or when not to use it. No 'use X instead' guidance is provided, leaving the choice to the agent based on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses Git side effects (fresh-sync, checkout fast-forward) and the hold behavior for unsafe states, preventing stale local handoffs. It stops short of explaining what 'holds' actually returns or whether the shared branch is mutated, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two focused sentences: the first states the action, the second details the branch-state safety conditions. It is dense with technical jargon like 'prompt/state/chain coordinates' but each sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no annotations, no output schema, and sparse parameters, the description omits critical details: what the tool returns, how it signals a hold, how loop_id identifies the loop, and the effect of include_prompt. It covers the Git sync and safety gate but leaves the agent unsure about invocation outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description never mentions loop_id or include_prompt. Since both parameters are completely undocumented in the schema and the description, the agent must guess loop_id's meaning and has no idea what include_prompt controls, even though include_prompt is optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Fresh-sync the shared Git branch, then resume the persisted rehydration loop at its exact current prompt/state/chain coordinates.' It distinguishes itself from siblings like rehydration_start or rehydration_advance by emphasizing exact coordinates and fresh-sync, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit conditions: 'Clean behind checkouts fast-forward; dirty, ahead, diverged, or unverified shared state holds rather than returning a stale local handoff.' This tells the agent when the tool can proceed and when it will hold, though it does not name specific alternative tools for the hold cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses crucial behavioral traits: the migration is additive, version 1 only inventories/pins, and it does not destructively rewrite organ tables. This goes beyond the basic 'apply' statement and provides essential safety-relevant context. Some gaps remain (e.g., error behavior, idempotency), but the added value 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, front-loaded with the main action, and no unnecessary words. Every word earns its place, making it easy for an agent to quickly parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is reasonably complete: it covers the action, sequence (next), and non-destructive nature. However, it leaves ambiguity around what constitutes a 'migration receipt' and how 'next' is determined, and does not describe return behavior or side effects beyond the safety note. This feels adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter ('actor') with no description, and schema description coverage is 0%. The description does not mention this parameter or add any meaning beyond the schema. Since coverage is low and the description fails to compensate, this dimension scores minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose with a specific verb ('Apply') and resource ('the next explicit additive schema migration receipt'). It also distinguishes from sibling tools like athena_schema_plan/status/verify by focusing on the apply step, and clarifies the version 1 behavior as inventory/pin rather than destructive rewrite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to apply the next migration) and provides context about being additive/non-destructive. However, it does not explicitly state when not to use it or mention alternatives like schema_verify or schema_plan for verification or planning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It mentions the exact-enumeration-only-below-threshold limitation and one-option recourse behavior, but omits output format, failure modes, side effects, and behavior above the threshold.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence front-loads the purpose and packs the process and limitation into two clauses. There is no filler, repetition, or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and incomplete parameter descriptions, the description is the only source of guidance. It explains the problem type and exactness limit but lacks return shape, risk_weight semantics, object schema details, and behavior above the finite threshold, making it insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining first_stage ('choose first-stage candidates') and scenarios ('per declared scenario'), and links exact_limit obliquely to 'finite threshold'. However, risk_weight is never mentioned, and the structure of object arrays is not specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'Solve a bounded finite two-stage resource problem' and specifies the algorithm structure: choose first-stage candidates, then best feasible one-option recourse per scenario. This clearly distinguishes it from sibling planning/solving tools by emphasizing finite, bounded, exact enumeration below a threshold.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: for finite two-stage resource problems with declared scenarios and exact enumeration. However, it lacks explicit 'use when' guidance, exclusions, or contrast with alternatives like athena_multistage_tv_dro_plan or athena_bapomdp_solve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits on its own. It does state that the operation moves a branch (state change) and requires a verified trigger, which is useful. But it doesn't mention reversibility, error behavior, required permissions, or what happens if the branch is not hibernated or trigger is unverified. This leaves significant gaps in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that gets straight to the point. It contains no filler or redundant information, and the action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description needs to provide a fairly complete operational picture. It fails to explain the meaning of basis_id, the verification process, what REVIEW status entails for the branch, or any postconditions. This is incomplete for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for branch_id, basis_id, trigger, or actor, and the description only indirectly explains trigger (must be of type new_evidence/new_gap/bridge_demand and 'verified'). It implies branch_id refers to the hibernated branch but does not explain basis_id or actor. With 0% schema description coverage, the description should compensate more, but it only explains a portion of the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moves a branch into REVIEW status, specifying the resource (hibernated branch) and the condition (verified trigger of specific types). This distinguishes it from branch-related siblings like athena_branch_list, athena_branch_observe, and athena_branch_state, which read state rather than change it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear precondition: the tool should only be used when a verified new_evidence/new_gap/bridge_demand trigger exists. This serves as a when-to-use guideline. However, it doesn't mention alternatives or contrast with other tools like branch_state or branch_observe, so it falls short of explicit sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses important behavioral traits: it works 'subject to observable remaining budgets' and explicitly states 'unknown cost is penalized, not invented', which clarifies it won't fabricate cost data. However, it does not mention side effects or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the action ('Allocate tasks to workers') and packs the entire allocation logic into a concise formula. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema, no annotations), this one-sentence description is incomplete. It omits parameter details, return behavior, and conditions under which it should be used, making it insufficient for an agent to fully understand the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so this description must compensate. It only alludes to tasks, workers, and remaining_budget conceptually, and does not explain optional parameters like alpha, beta, scope, or max_assignments_per_worker. This is inadequate for a 7-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: 'Allocate tasks to workers' and provides the allocation formula (demand x capability fit x availability x measured efficiency) plus the key constraint of penalizing unknown costs. This distinguishes it from sibling tools like athena_collective_allocate by specifying its unique approach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's usage is implied through 'Allocate tasks to workers ... subject to observable remaining budgets', but there is no explicit guidance on when to choose this over alternatives like athena_schedule_multiperiod or athena_collective_allocate. It lacks exclusions or direct comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Read' clearly indicates a read-only operation, but the description does not disclose what happens for invalid claim_ids, whether any special permissions are required, or what the actual return format is. For a simple single-parameter read, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the verb and resource. No filler or unnecessary detail. It is as concise as possible while conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no output schema, and no annotations, so the description is the only guidance. For a simple read, the description covers the basic purpose, but it does not explain domain-specific terms ('typed authority state', 'witness history pointers') or mention potential errors or return values. It is minimal but not fully sufficient for an unfamiliar agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain claim_id. It adds the semantic that the tool operates 'for one claim,' implying claim_id identifies the specific claim. However, it does not explain the format or origin of claim_id, or clarify what 'typed authority state' and 'witness history pointers' mean in relation to the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and identifies a clear resource ('typed authority state and witness history pointers') scoped to 'one claim.' This distinguishes it from sibling tools like athena_claim_list (which lists claims) and athena_claim_challenge (which challenges a claim).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use the tool (when you need to read the current state of a single claim), but it does not explicitly name alternatives or state when not to use it. With many sibling tools, some exclusionary guidance would help, but the context is implied by the wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining side effects. It discloses idempotency, the shared-board presence prerequisite, and the fact that it does not assign work, which are valuable. However, it omits details such as whether publishing is persistent, visible to all board members, or has failure modes related to duplicate request_id values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the core action and followed by two high-value constraints. Every sentence 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (21 params, no annotations, no output schema), the description is far from complete. It provides a good high-level orientation but fails to explain required field relationships, return values, error conditions, or the semantics of optional fields, making it insufficient for safe invocation in many scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 21 parameters, and the description adds only minimal meaning: it explains the 'kind' parameter (NEED/OFFER) and hints at the agent context via 'active shared-board presence.' It does not explain critical fields like request_id, capabilities, goal_ref, targets, or acceptance_criteria, leaving the agent to infer their semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: to publish an idempotent typed NEED/OFFER envelope through Message Board V1. It distinguishes the tool by emphasizing that it does not assign work and requires active shared-board presence, which differentiates it from cohesion siblings like matchmaking or work-assignment tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: the publishing agent must already have active shared-board presence, and the tool does not assign work. It implies when to use it (publishing NEED/OFFER envelopes) but does not explicitly name alternative tools or exclusion scenarios, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'DESIGN_ONLY' usefully signals that the tool does not execute the policy, but the description does not state whether the design is persisted, what is returned, or whether the belief state is modified. Key side-effect questions remain unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a clear imperative and a terse, high-signal qualifier 'DESIGN_ONLY.' Every word adds meaning, and it avoids redundant restatement of the input schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three required parameters, nested objects, no output schema, and no annotations, the tool needs a richer description. It states the core purpose but omits return format, parameter structures, side-effect expectations, and guidance for the actions array. It is not complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and no parameter descriptions are present. The phrase 'one supplied experiment' maps to the experiment parameter, and 'current finite belief' hints at context_key, but the actions array and exact meaning of context_key are left unexplained. The description only partially compensates for the undocumented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Build' and names the exact artifact: 'depth-1 outcome-contingent action policy.' It adds scoping conditions ('under the current finite belief and one supplied experiment') and distinguishes itself from execution-oriented or multi-stage policy tools via 'DESIGN_ONLY.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear invocation context: depth-1, current finite belief, one supplied experiment, and design-only mode. It does not explicitly name alternatives or state when not to use the tool, but 'DESIGN_ONLY' and 'depth-1' imply boundaries versus execution or multistage planning tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 that credit assignment is uncertainty-bearing, that weak designs only yield associational conclusions (a caveat about interpretation), and that residual outcome is preserved (implying non-destructive behavior). This adds meaningful context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundant wording. The first sentence states the action, and the second adds a caveat. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 6 parameters, nested objects, and no output schema, the description is too brief. It omits critical details like the meaning of outcome_key, the structure of the design object, what regime/actor represent, and what the tool returns. The caveats are useful but do not compensate for the missing operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only implicitly references 'outcome_delta' and 'interventions' but leaves outcome_key, design, regime, and actor unaddressed. No parameter descriptions exist in the schema, so the agent has insufficient information to fill these fields correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Assign') and resource ('uncertainty-bearing intervention credit') derived from an observed outcome delta. It distinguishes from siblings like athena_credit_summary (summary) and athena_delayed_credit_record (delayed) by specifying the immediate credit assignment mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have an outcome delta and interventions to assign credit, and notes that weak designs remain associational. However, it does not explicitly state when to use this tool over alternatives like athena_delayed_credit_record or athena_interaction_credit, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose a key safety behavior: 'It never deploys or grants cutover authority,' which is valuable. However, it does not explain whether the tool writes any state (e.g., persists the plan), what permissions are required, or what the output format is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a tightly written two-sentence structure, front-loading the core action and constraints in the first sentence and a critical non-behavior in the second. Every word contributes meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 11 parameters (7 required), no annotations, and no output schema. The description only provides high-level purpose and a safety disclaimer, leaving parameter semantics, return value, and operational prerequisites unexplained. An agent would struggle to invoke it correctly without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 11 parameters. Terms like 'source-bound,' 'digest-pinned,' and 'isolated-canary' hint at potential parameter mappings (e.g., source_head, state_snapshot_digest, canary_percent) but are left ambiguous. The agent must make unguided inferences to correctly populate required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to compile a PLAN_ONLY, source-bound, digest-pinned, isolated-canary, CAS single-writer cutover plan. It also explicitly distinguishes itself from deployment tools by stating 'It never deploys or grants cutover authority,' making the action and scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes a clear usage context: this tool is for planning only, not execution. The phrase 'It never deploys or grants cutover authority' serves as an explicit when-not-to-use signal. However, it does not name specific alternative tools, so it lacks full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It discloses one key behavior: 'never promotes Y1 authority.' However, it does not mention potential side effects, permission requirements, reversibility, or return behavior, leaving significant transparency gaps for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences that front-load the core purpose and add a critical behavioral qualifier. No unnecessary words or repetition; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, including nested objects, no output schema, and no annotations. The description provides only a minimal overview of what the tool does and does not explain what constitutes a 'science-shadow witness,' how 'result' is used, or what happens after attaching. This is insufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only adds meaning for 'kind' (the three possible values SUPPORTS/FALSIFIES/INCONCLUSIVE) and 'independence_key' (explicit). The remaining parameters (claim_id, result, evidence, confidence, actor) are not explained in the description or schema, leaving the agent to guess their semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach'), the resource ('science-shadow witness'), and the specific classification values ('SUPPORTS/FALSIFIES/INCONCLUSIVE'). It also distinguishes this tool from sibling tools by clarifying that it does not promote Y1 authority, which sets it apart from related claim/witness operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when attaching a science-shadow witness with an explicit independence key) and provides a clear exclusion: it never promotes Y1 authority. However, it does not explicitly name alternative tools or provide detailed when-not-to-use scenarios, so it stops short of being fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of transparency. It discloses an optional side effect ('optionally records successful antibody hits') and implies a read operation. However, it does not clarify the scope of the read, any mutation side effects beyond recording, or the behavior 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the primary action, target, and optional side effect without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters and no output schema or annotations, yet the description only provides a high-level summary. It omits parameter semantics, output details, and edge-case behavior, making it insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only hints at 'event' and 'record_hits' through the phrase 'records successful antibody hits.' The other parameters (tags, limit, scope, threshold) are unexplained. This is insufficient compensation for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'match' and identifies the resource (durable antibody registry) and the expected outputs (reusable repairs and regression witnesses). It clearly differentiates from sibling tools like athena_failure_antibody_register, which focuses on registration rather than matching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Match a new failure/event' establishes a clear trigger for using the tool. It doesn't explicitly list alternatives or exclusions, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and succeeds richly. It discloses key behaviors: proposals are UNMEASURED, identical signatures only merge provenance, conflicting ranking/routing data fail closed to CONFLICT, disputed operands are removed, and semantic similarity never merges. This is substantial beyond what any structured field could convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two dense sentences with no filler. Key behaviors are front-loaded, and every clause adds unique information about merging, conflict resolution, or output type. It is appropriately compact for the complexity it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex schema, no annotations, and no output schema, so the description must do more heavy lifting. It explains the core compilation and conflict rules well, but it omits critical context such as the role of seed_ref, the effect of persist, and the shape of the returned FIELD.1 candidates. This is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for 'module_outputs' (interpreting them as SX/RAG/Y/GAP/HUG/branch/AOR residuals) and hints at 'explicit_candidates' through 'explicit ranking/routing data,' but it leaves seed_ref, actor, persist, and ecosystem entirely unexplained. This is insufficient for a 6-parameter schema with no parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'assemble' and the resource: it takes SX/RAG/Y/GAP/HUG/branch/AOR residuals and produces 'typed FIELD.1 action candidates.' This is specific enough to separate it from generic 'field' tools like athena_field_get or athena_field_replay, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: this tool should be used when one has residuals from the named modules and needs to compile them into action candidates. However, there is no explicit 'when to use' vs 'when not to use' guidance, and no alternatives are mentioned, making it more implied than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does disclose a key trait: the tool avoids expanding full candidate payloads, which helps set expectations about response size. However, it omits other useful context like ordering, pagination behavior, or whether receipts include timestamps, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that front-loads the verb and resource, then adds a meaningful qualifier. No filler words, no redundancy, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with a single optional limit parameter, the description is mostly complete. It tells the agent what the tool returns (receipts) and what it deliberately avoids (full candidate payloads). The main gap is the lack of any output structure, which is mitigated by the simplicity of the tool and the 'receipts' concept.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% because the description never mentions the 'limit' parameter. While the schema fully documents the limit with minimum and maximum bounds, the description adds no extra meaning (e.g., how limit interacts with 'recent' or whether it is optional). Given low coverage, the description should have compensated but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('List') and a specific resource ('recent persisted FIELDRUN receipts'). The qualifier 'without expanding full candidate payloads' further differentiates it from tools like athena_field_get or athena_field_replay that likely handle expanded payloads or replay behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when needing a lightweight list of recent field-run receipts) but does not explicitly state alternatives or exclusions. It never names sibling tools like athena_field_get or athena_field_replay, so an agent must infer the right choice from the 'without expanding' hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses 'Read-only' and specifies the computation method (marginal likelihood and visible priors), which is helpful. However, it does not describe the return value or potential errors, and since there is no output schema, this is a notable omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action and safety. Every word contributes meaning, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must explain return values and parameter semantics. It covers the core computation and read-only nature, but omits the return format and leaves a required parameter ('context_key') undocumented. This makes it incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must compensate. It relates 'candidates' to the hyperparameter grid, but it does not explain the 'context_key' parameter or the expected structure of the candidate objects. This incomplete coverage leaves the agent guessing on key input details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes a normalized posterior over a GP hyperparameter candidate grid, using a specific verb ('Compute') and resource. It distinguishes itself from siblings like athena_gp_hyperfit by explicitly focusing on posterior calculation rather than fitting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when a normalized posterior over a finite explicit candidate grid is needed. It does not explicitly mention alternatives or exclusions, so it stops short of a 5, but the applicability is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 important validation behaviors (frozen output schema, verified receipt), which adds context beyond a bare 'complete' verb. However, it does not describe side effects, idempotency, failure modes, or what 'Complete' actually finalizes, leaving significant transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero waste. It packs the verb, resource, and key validation criteria into 16 words. This is a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 provides a minimal but sufficient overview for a simple tool. It explains what must be provided (planned invocation, validated output, verified receipt) but omits post-completion behavior, return format, and lifecycle context. Given the sibling tool names (e.g., athena_hug_fail, athena_hug_plan), one can infer the workflow, but the description itself is thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially does by linking 'PLANNED HUGINV' to invocation_id, 'output' to the output property, and 'verified execution receipt' to the receipt object. However, the optional 'actor' parameter is unaddressed, and the receipt's 'ref' field is not explained, so the semantics are incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Complete') and resource ('PLANNED HUGINV'), adding critical conditions ('output validated against frozen output schema and a verified execution receipt'). This clearly distinguishes it from sibling tools like athena_hug_fail (opposite action) and athena_hug_plan (creates the plan).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'PLANNED HUGINV' implies a prerequisite (a prior planning step) and the requirement of a 'verified execution receipt' suggests prior verification, but there is no explicit 'use this when...' or 'instead of...' language. The guidance is implied through contextual terms rather than stated directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It clearly indicates the response includes a frozen snapshot and either an output/receipt or failure, which sets expectations about the return payload and possible failure modes. However, it doesn't explicitly state read-only behavior or error handling beyond the word 'failure'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. Every component it lists adds value, and the structure flows naturally from the core action ('Fetch one HUGINV') to the detailed contents of the return object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description provides a surprisingly detailed inventory of the returned object, covering snapshot, arguments, context, status, and outcome. It stops short of defining the 'six arguments' or 'context', but for a fetch operation this level of detail is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description never mentions the invocation_id parameter or its role in selecting the HUGINV. While the parameter name is self-explanatory, the description fails to compensate for the lack of schema documentation, leaving a semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and names the resource 'HUGINV', then enumerates the returned components: frozen implementation snapshot, six arguments, context, status, and output/receipt or failure. It explicitly says 'one' to distinguish from list-style tools like athena_hug_list, making the tool's scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not name any sibling tools, state prerequisites, or explain when a user would prefer this over athena_hug_state or athena_hug_list, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides a notable behavioral caveat: missing 2x2 cells remain UNIDENTIFIED. However, it does not state whether the tool mutates inputs or what side effects occur, leaving the no-annotation burden only partially met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler; first sentence front-loads the verb and object, second adds a critical caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description should explain the expected structure of 'experiments', the purpose of 'analysis_key', and the output format of the contrasts. It does not cover these, though the unidentified-cells warning is useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover none of the three parameters. The description only loosely connects 'experiments' to intervention/outcome observations, and leaves 'analysis_key' and 'actor' undefined, so the agent lacks needed parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: estimating main and pairwise interaction contrasts. The phrase 'from supplied intervention/outcome observations' defines the input context, and the name 'interaction_credit' distinguishes it from credit assignment/summary siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete usage context ('supplied intervention/outcome observations') and the statistical goal, so an agent can infer when to select it. It does not explicitly name alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states two important behaviors: 'Unknown state coordinates/non-finite transitions fail closed' and 'PLAN_ONLY'. These go beyond the default 'solver' behavior and provide practical guidance on failure modes and output scope, though it does not detail all error handling or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences, with the core purpose front-loaded and the second sentence adding critical behavioral context. Every word carries meaning, with no padding or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 6 parameters, a nested object (actions_by_state), no output schema, and no annotations. The description, while dense, does not provide enough information for an agent to correctly construct the input, particularly the actions_by_state mapping, nor does it describe the plan output or the meaning of 'fail closed' in operational terms. Major invocation details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not name or explain individual parameters. It hints at 'supplied transition distributions' and 'total-variation ambiguity', which relate to actions_by_state and tv_radius, but does not define their structure or format. The nested 'actions_by_state' object remains completely opaque, so the description fails to compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Solve') and resource ('bounded finite-horizon robust dynamic program') with a precise ambiguity class ('state-action rectangular total-variation ambiguity') and a mode ('PLAN_ONLY'). It distinguishes itself from siblings by naming the unique technical approach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by defining a precise problem class, but it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or fallback tools. The usage context is embedded in the technical jargon rather than stated directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It meaningfully reveals that formation 'emits a durable party event but earns no XP', which are non-obvious side effects. It also states the leader prerequisite. It could add details about permissions or reversibility, but for a creation action it provides useful transparency beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and each sentence earns its place: the first states the core action and context, the second adds a precondition and key behavioral outcomes. There is no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters, zero schema description coverage, and no output schema, the description is far too minimal. It covers the basic purpose and one precondition, but leaves all parameter semantics, return behavior, and edge cases unexplained. An agent could not reliably construct a valid invocation with only this description and the bare schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention any of the 9 parameters, including the 4 required ones (party_id, leader, goals, leader_goal_refs). The description adds no meaning to the input schema, leaving agents to guess the semantics of fields like role, remote, purpose, capacity, and capabilities. This is a critical gap for a tool with this many parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation with a specific verb ('Form') and a specific resource ('Git-shared multi-goal party on top of Message Board V1'). This distinguishes it from sibling tools like athena_party_join, athena_party_list, and athena_party_state, which cover different phases of a party's lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear precondition ('leader must already be actively present on the shared board') and specifies the context ('on top of Message Board V1'). It does not explicitly name alternative tools, but the action of forming a party makes its role distinct from joining, listing, or observing parties, so usage is fairly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that goal ownership, role, capabilities, task relation, and current board claim are 'frozen' into the shared party record, indicating immutability after joining. However, it does not mention side effects like reversibility, permissions, or failure behavior, leaving significant behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence that is front-loaded with the core action and includes a meaningful constraint (Message Board V1). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description is thin. It does not describe return values, error conditions, or the full effect of freezing on subsequent operations. The unqualified reference to 'Message Board V1' and the ambiguous 'current board claim' leave gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden. It mentions 'role', 'capabilities', 'task relation', and vaguely references 'goal ownership' and 'current board claim', but does not explain parameter purposes, allowed values, or the meaning of goal_refs, party_id, agent, or remote. The enum in task_relation is undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Join an existing party') and the resource ('shared party record'), and clarifies a prerequisite (already present on Message Board V1). It distinguishes from siblings like athena_party_form by indicating it joins an existing party.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear precondition ('while already present on Message Board V1') and implies the tool is for joining rather than forming (sibling athena_party_form). However, it does not explicitly name alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals two key behaviors: rejecting stale expected_version (optimistic concurrency) and recording rollback history. However, it doesn't mention potential side effects, error handling on rejection, or whether the update is atomic/persistent. These additions add value but leave some behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and then adds two specific behavioral details. Every word earns its place, with no unnecessary fluff. It is appropriately sized and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects, no output schema, no annotations), the description is far from complete. It doesn't explain what 'bounded' or 'online' means, what the return value is, or how errors like stale version rejection are surfaced. The description covers the core purpose but leaves many operational and behavioral details unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only hints at the meaning of expected_version and observed_reward. The other five parameters (l2, actor, scope, learning_rate, features) are completely unexplained. The description adds minimal semantic value beyond the schema, leaving most parameters ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a versioned, bounded online policy update from an observed reward. It distinguishes itself from siblings like policy_rollback and policy_score by emphasizing the update action and the observed-reward input. The specific behaviors of rejecting stale versions and recording rollback history further clarify its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you have an observed reward and want to update the policy with versioning), but it does not provide explicit exclusions or mention alternative tools. No guidance is given about when to prefer this over the rollback or score tools. This is an implied usage rather than a clear directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the operation is a fetch (implying read-only) and specifies the returned contents (certificates, attestations, trust state, etc.). However, it does not mention error behavior, auth requirements, or idempotency explicitly, leaving some behavioral aspects unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no redundant information. Every clause adds a meaningful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single parameter and no output schema, so the description's summary of the fetched object's attributes (certificates, attestations, trust state, status, decision digest) helps compensate. The note about historical receipts remaining readable adds useful context. Minor omissions like error handling are acceptable for a simple get operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explicitly explain the 'run_id' parameter, though it indirectly refers to the PROMRUN resource. Since schema coverage is 0%, the description should compensate for parameter semantics, but it adds no additional detail about the parameter's format or purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Fetch one persisted versioned PROMRUN' with a specific list of contained attributes, distinguishing it from sibling tools like athena_promotion_recent or athena_promotion_replay by indicating it retrieves a single persisted object. The verb 'Fetch' and resource 'PROMRUN' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to retrieve a specific promotion run by ID) but does not explicitly compare it with alternatives like athena_promotion_evaluate or athena_promotion_recent. No explicit exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden but offers meaningful behavioral detail: it freezes exact source refs, converts missing expected refs into defects, and explicitly does not imply searched for unlisted/unavailable sources. However, it does not disclose potential overwrite behavior, return values, or the role of the 'persist' parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with the verb and resource front-loaded. Every word contributes: the first sentence states the primary action and the second clarifies edge-case behavior with defects and implied searches. No wasted phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description gives essential behavior but not full completeness. It clarifies core semantics and negative guarantees but leaves 'actor', 'persist', and what 'freezing' implies for the output or existing state ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the core parameters: 'source refs actually consulted' (source_refs) and 'optional expected refs' (expected_refs). It does not explain 'task_ref', 'actor', or 'persist', leaving a notable gap for those parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Persist a RECONRUN') and the specific objects involved ('current Ω', 'exact source refs', 'optional expected refs'). It distinguishes itself from siblings like athena_reconstruction_get/recent/verify by making the persistence role explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after a reconstruction run to persist state, but does not explicitly state when to use this tool versus alternatives or mention any exclusions. It provides no direct 'when to use' guidance beyond the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about mode restrictions and prerequisites (program and metric), but it does not disclose side effects, return behavior, error conditions, or whether the registration persists. This is some meaningful context, but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, no filler. The first sentence defines the core purpose, and the second adds a critical constraint. Every word earns its place given the dense technical content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity tool with 10 parameters, nested objects, and no output schema. The description is far too brief to be complete: it doesn't explain the modes in detail, parameter formats, how to construct the 'safe declarative program', or what the response looks like. It provides only a skeletal framing for an operation that likely requires significant additional specification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 10 parameters and 0% description coverage, so the description must significantly compensate. It does connect 'program' and 'metric' to derivational mode requirements and implies src_chart/dst_chart via the T_ij:C_i->C_j notation. However, the remaining 6+ parameters (actor, status, loss_model, operator_oid, operator_vid, etc.) are entirely unexplained, leaving a major semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Register a typed coordinate transform T_ij:C_i->C_j', using a specific verb and resource with a precise mathematical signature. It distinguishes itself from siblings like athena_apply_transform by focusing on registration rather than application or navigation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that LOOKUP is 'navigational only' and that derivational modes require 'a safe declarative program and explicit comparison metric', giving clear conditions for use. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It reveals that the tool persists to Git, checkpoints state, and does not create background execution. However, it doesn't explicitly mention potential side effects like overwriting existing state or requiring specific Git head conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the main action and adds a critical behavioral qualifier. Every sentence contributes to understanding the tool's operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 16 parameters, no annotations, and no output schema, the description is far too brief. It doesn't explain return values, prerequisites, or what constitutes a valid invocation, leaving the agent without essential information beyond the schema's bare property names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its 16 parameters, and the description does not compensate. Terms like 'bounded self-prompt' and 'frontier/state coordinates' hint at some parameters but provide no direct mapping or explanation for fields like 'goal', 'expected_git_head', 'max_steps', or 'shared_remote_mode'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('start', 'compile', 'checkpoint') and identifies the resource ('Git-persisted explicit rehydration loop'). It clearly distinguishes this from siblings like athena_rehydration_advance and athena_rehydration_verify by focusing on initialization and checkpointing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use it: to start a Git-persisted explicit rehydration loop, compile the first prompt, and checkpoint coordinates. The explicit statement 'This creates no background execution' offers a useful constraint for selection, though it doesn't name alternatives or exclusions explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. 'DESIGN_ONLY' hints at a non-executing, likely read-only or pure-computation behavior, which adds some transparency. However, it does not disclose whether state is modified, what the output format is, or any side effects. More detail on the ranking process or return structure would improve this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, essential information front-loaded, no wasted words. The acronym 'DESIGN_ONLY' is a compact way to convey the design-only constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no annotations, and no output schema, the description is too sparse. It does not explain what the tool returns, the semantics of key parameters, or how to use it in the broader workflow. The description covers purpose but leaves the agent to guess at parameter behavior and output interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It only vaguely references 'cost and risk' (matching cost_weight and risk_weight) and 'designs' (matching candidates). It does not explain the role of 'mode', 'dimensions', or the structure of 'candidates'. This is a significant gap for a 6-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Rank'), specific object ('proposed REPLICATION or FALSIFIER designs'), and the ranking criteria ('expected power, metadata novelty, feasibility, cost and risk'). This distinguishes it from sibling tools like athena_experiment_design, which are less specific. The 'DESIGN_ONLY' tag adds further scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use when you have proposed replication or falsifier designs to rank. The 'DESIGN_ONLY' tag implies it is not for executing or implementing designs, which is a mild exclusion. However, it does not explicitly name alternative tools or provide explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the burden. It discloses one key behavioral trait (no payload expansion) and mentions persistence, but does not describe ordering, return fields, or whether the list is limited to a particular scope beyond 'recent.' It adds some useful context but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that immediately states the action and resource. No wasted words, and the qualifier about payloads is efficiently included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description adequately covers the core purpose and a key limitation. It does not fully explain behavioral details like the meaning of 'RAGRUN receipts' or ordering, but for a straightforward listing tool, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'limit' parameter at all. The schema offers basic type and min/max constraints, but the description provides no additional meaning for the parameter, failing to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies the exact resource ('recent persisted RAGRUN receipts') with a distinguishing qualifier ('without expanding full candidate payloads'). This clearly separates it from siblings like athena_retrieval_get and athena_retrieval_replay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without expanding full candidate payloads' implies when not to use this tool if full payloads are needed, but no explicit alternative is named. Clear context is provided for listing recent receipts, yet there is no direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Always SIMULATE_ONLY' clearly discloses the key behavioral trait of no side effects, which is critical for an AI agent. It also hints at the output nature with 'uncertainty-banded discounted return', but does not cover potential errors or state mutations beyond the simulation guarantee.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two short sentences that front-load the primary action and key constraint. Every word adds value, and there is no redundant or ambiguous language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, 2 required, nested objects, no output schema, and no annotations. The one-sentence description does not explain parameter relationships, expected format for nested objects, or return structure, making it inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must explain parameters, but it only hints at semantics via terms like 'trajectories', 'discounted', and 'uncertainty'. It does not explicitly describe what 'initial_context', 'trajectories', 'discount', 'prior_strength', or 'uncertainty_alpha' contain or expect, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Simulate' and explicitly names the resource 'multi-step trajectories through the learned transition model', distinguishing it from sibling tools like athena_rollout_simulate by highlighting the learned model and uncertainty-banded discounted return. The additional 'Always SIMULATE_ONLY' clarifies its safe simulation scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for simulation-only scenarios via 'Always SIMULATE_ONLY', but it does not explicitly compare it to alternatives like athena_rollout_simulate or state when not to use it. There is no clear exclusion or when-to-use guidance beyond the implied safe simulation context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects, authentication needs, or operational constraints. It uses the verb 'Return' which implies a read-only operation, but does not explicitly state safety properties, prerequisites (e.g., server must be running), or potential performance impacts. The description focuses on content provenance rather than behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the primary action and resource, then efficiently lists derivation sources without unnecessary filler. Every clause adds specificity, making it appropriately concise for a complex manifest tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description partially compensates by enumerating content areas (schema/startup, Collective/AOR organs, unresolved semantics, Git status). However, it does not describe the return structure, format, or any failure modes. It also assumes background familiarity with 'ATHENA.RUNTIME.UNIFIED.1' and does not clarify prerequisites beyond 'running Server' implicitly. More detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which sets a baseline of 4. The description adds no parameter-specific details (none are needed), and the empty input schema is fully covered. The description provides context about the output instead, which is appropriate for a parameter-less tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Return') and resource ('live ATHENA.RUNTIME.UNIFIED.1 architecture manifest'). It further distinguishes itself from sibling tools by enumerating the exact derivation sources (running Server, schema/startup state, Collective/AOR organs, unresolved semantics, exact Git status), making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when a comprehensive runtime architecture manifest is needed) and hints at its coverage, but it does not explicitly contrast with sibling tools like athena_git_status or athena_schema_status, nor provide exclusions. Usage context is implied rather than directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavior: it returns an exact certificate only if search completes, and otherwise degrades explicitly. This is valuable transparency. It doesn't mention side effects or detailed degradation semantics, but for a scheduling tool this covers the main risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action, and every phrase adds value. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, nested objects, and no output schema. The description covers the overall purpose and key behavior, but lacks details on parameter structure, tuning limits (max_nodes, exact_task_limit), and what 'degrades' means in the return value. For a moderately complex tool, this leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the meaning of tasks, workers, horizon, and budget, but leaves discount, max_nodes, and exact_task_limit undocumented. The core domain semantics are present, but not all 7 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exhaustively enumerates schedules with specific constraints (dependencies, worker capability, horizon, budgets). It distinguishes itself with 'small finite' and 'exact certificate', differentiating it from the sibling athena_schedule_multiperiod. However, it does not explicitly name that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for small finite scheduling problems where an exact certificate is desired, and mentions degradation if search doesn't complete. It does not provide explicit when-to-use or exclusion criteria relative to other scheduling tools, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without any annotations, the description carries the full burden. It states it computes a surface, implying a pure, read-only operation, but does not disclose the exact output structure (e.g., matrix shape), edge cases, or any performance characteristics. It's adequate but lacks richer behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-structured sentence that front-loads the core computation 'Compute a two-dimensional sensitivity surface' and then specifies the inputs. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter computational tool with no output schema, the description gives the essential purpose and parameter meaning but omits details about the exact return format and interpretation of the surface. It's complete enough to understand the task but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that exposure_confounder_rrs and outcome_confounder_rrs represent strengths of exposure-confounder and confounder-outcome relationships, and observed_rr is implied as the observed risk ratio. However, it does not explain value ranges or the meaning of the resulting surface values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Compute' and names the exact resource: 'a two-dimensional risk-ratio bias-factor sensitivity surface.' This clearly distinguishes it from sibling tools such as athena_sensitivity_evalue by specifying the 2D surface nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage for sensitivity analysis given two confounder strength arrays, but does not explicitly state when to prefer it over alternatives like athena_sensitivity_evalue or athena_causal_robustness. No exclusions or alternatives are mentioned, so it only achieves the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the read-only nature, the pooling of duplicate support coordinates before PAV, and the caveat that the result is not a causal graph posterior. This goes beyond a simple restatement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and packs the main action, method, and caveat efficiently. It is front-loaded with the verb and resource, and every clause adds context. It is dense but not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with 4 parameters and no output schema or annotations. The description covers the core method and a key caveat, but lacks details on return values, parameter formats, and usage prerequisites. Given the lack of schema descriptions, it is sufficient but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters. It only hints at 'supports' via duplicate coordinates and 'folds' via out-of-fold, but the calibration_examples, seed, and folds parameters are not defined. With zero schema coverage, the description should compensate, but it doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: calibrating structural support against externally labelled correctness using a specific method (weighted out-of-fold isotonic reliability). It distinguishes itself by noting it is not a causal graph posterior, which separates it from sibling causal tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when calibration of structural support is needed, and mentions 'externally labelled correctness' as the reference, but it does not explicitly state when to prefer this over alternatives or provide exclusion criteria. No alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses that matches never auto-execute and that measurement/testing remains required, which is crucial for an agent to set expectations. However, it does not mention side effects like persistence behavior or mutation of existing data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, no filler. Every phrase adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a complex input schema with nested objects and no output schema, the description provides only the core purpose and one caveat. It lacks explanation of required fields, the meaning of 'UNMEASURED FIELD', what happens with 'persist', and expected return value, making it incomplete for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only indirectly references 'matches' via 'failure-antibody matches'. It does not explain the 'failure_ref', 'actor', or 'persist' parameters, nor the structure/semantics of the matches array, leaving the agent without sufficient parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Translate') with a clear source ('explicit failure-antibody matches') and destination ('UNMEASURED FIELD repair candidates'), which distinguishes it from sibling transport tools like athena_transport_alarm_to_gap and athena_transport_aor_to_collective.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you have failure-antibody matches) but does not explicitly compare to alternatives or state when not to use it. The caveat about not auto-executing is more about behavior than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses that economics are never derived from the AOR bridge score, which is a valuable behavioral constraint. However, it doesn't mention side effects (e.g., whether it mutates the collective packet or just returns a packet), nor does it discuss the persist parameter's effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and includes a critical caveat. Every word earns its place; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, a nested required economics object, no output schema, and no annotations, the description is too brief. It doesn't explain the economics fields, the role of actor and persist, or what a successful transport returns or changes. The caveat is helpful but insufficient for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only provides high-level context: 'bridge economics' maps to the economics object and 'AOR bridge candidate' maps to candidate_ref. It does not explain individual parameters like actor, persist, or the nested economics fields, leaving the schema alone to carry semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Carry explicit bridge economics') with a defined source ('AOR bridge candidate') and destination ('Collective bridge-accounting packet'). It distinguishes from sibling transport tools by focusing on bridge economics and the AOR bridge context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you have explicit bridge economics to transfer. It doesn't explicitly name alternatives or exclusions, but the 'never derived' caveat provides some guidance. Good context but no explicit when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the tool 'never populates relevance, source_authority, evidence, confidence or Y authority,' which is a critical limitation for an agent to know. It also clarifies it is an 'adapter,' suggesting a non-mutating role, but does not disclose potential side effects, permissions, or persistence behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and followed by a concise behavioral limitation. Every word contributes value; there is no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no output schema, no annotations) and the existence of many related transport tools, the description is incomplete. It lacks usage guidance, parameter explanations for actor and persist, and any mention of return values or side effects. The behavioral note is valuable but insufficient for an agent to select and invoke the tool with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It only indirectly covers 'route_keys' via 'named routes' and provides no explanation for 'actor' or 'persist'. The description fails to clarify the purpose or semantics of the other two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Freeze' with a precise resource: 'Collective-V2 pheromone state for named routes into AOR/RAG attention-prior packets.' It clearly differentiates from sibling tools by naming the exact packet type and adapter behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by describing the core function (freezing pheromone state into attention-prior packets) but provides no explicit guidance on when to prefer this tool over alternatives. It does not mention any sibling tools or exclusions beyond the 'never populates' caveat, which is a weak exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosure. It does disclose meaningful behavior: noncanonical claims are moved to '?/CHALLENGED', canonical claims remain '#/CANONICAL_CHALLENGED', and automatic routing is blocked. This goes beyond the schema and helps agents anticipate side effects, though it does not cover all possible failure modes or prerequisite conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and wastes no words. It opens with the primary action ('Record...') and then provides the key behavioral consequence. Every token earns its place, making it easy for an agent to quickly parse the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the overall outcome and even the state transition details, but it leaves critical gaps: the meanings of the parameters, especially witness.ref and reason, are absent, and there is no output schema or annotation to fill those holes. The agent can understand what the tool does but may not know how to populate the fields correctly, so it is only a minimally viable description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it does not explain any of the four parameters (claim_id, witness, reason, actor) or the nested structure of the witness object. The word 'verified' loosely maps to witness.verified, but no concrete guidance is given on the semantics of ref, reason, or actor, which is inadequate for a tool with a required nested object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Record a material verified challenge.' It also distinguishes the two outcome branches (noncanonical vs canonical claims) and the resulting statuses, making it clear how this tool differs from other claim-related tools like athena_claim_list or athena_claim_resolve_canonical_challenge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for material verified challenges and notes a behavioral consequence (blocking routing for canonical claims), but it does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions. The context is present but not as explicit as the top of the scale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden and does well: it discloses persistence, the greedy OFFER-capacity algorithm, and the advisory-only, side-effect-free nature regarding presence, claims, membership, and authority. It does not, however, mention authentication/authorization requirements or error/failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with no filler; each clause adds substantive detail. It loses a point because the heavy use of jargon (Message Board, NEEDs, OFFER capacity) and a long list of exclusions makes it somewhat harder to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, and no output schema, this description provides high-level intent and important exclusions but omits critical invocation details such as parameter meanings, return value shape, failure conditions, and how OFFER capacity is supplied. It is adequate for selection but not for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the 7 undocumented parameters. It only indirectly references need_ids via 'NEEDs' and offers via 'OFFER capacity,' leaving remote, exit_criteria, rendezvous_refs, max_participants, and the required identifiers unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Build and persist a Message Board-backed campaign/coalition proposal over multiple active NEEDs.' It clearly differentiates this advisory tool from siblings that create presence, claims, party membership, scheduler authority, or execution authority.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a non-binding proposal across multiple active NEEDs is needed, and explicitly notes it creates no presence/claims/party membership/etc., which helps an agent avoid this tool when actual authority or execution is required. However, it does not name alternative tools or give explicit 'when not to use' instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses filtering (only planned) and ordering, but does not mention pagination, return format, error behavior, or whether run_id must exist. It adds some behavioral context beyond the schema but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core action and resource. Every word contributes meaning, no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description is partially adequate. It covers purpose and ordering but omits parameter clarification and behavioral details like result size or error conditions. Given the absence of annotations and output schema, more context would help, though the low complexity keeps this at a passable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain run_id beyond the schema's name. It references 'for an extraction run' but provides no detail on what a run_id is, how to obtain it, or any constraints beyond minLength. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Return' with a resource ('currently PLANNED tasks for an extraction run') and adds ordering criteria ('depth/ordinal/id'). It clearly distinguishes from sibling tools that handle completed tasks or results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear usage context: use this tool when you need only planned tasks for an extraction run. It does not explicitly name alternatives, but the 'only currently PLANNED tasks' phrasing sets an exclusion. No explicit when-not-to-use guidance, hence not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden of behavioral disclosure. It discloses that the tool covers 'persisted' receipts and avoids expanding graph snapshots, which is useful. However, it does not explicitly state that the operation is read-only or non-destructive, nor does it define what 'recent' means in terms of time window or ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that front-loads the verb and object, with no wasted words. Every element—'recent,' 'persisted,' 'without expanding full graph snapshots'—contributes meaning, achieving high conciseness and effective structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool with no output schema, the description provides the core purpose but lacks important contextual details such as the definition of 'recent' (time window or entry count), what a GAPRUN receipt looks like (fields or format), and any pagination behavior. It is adequate for basic understanding but leaves gaps that could affect correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% because the description never mentions the optional 'limit' parameter. The schema provides type and range (1–500), but the description adds no meaning about how 'limit' affects results, such as the default number of receipts returned or whether it is a maximum count. The agent must guess the parameter's role solely from its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear object ('recent persisted GAPRUN receipts'), distinguishing it from heavier gap tools by adding 'without expanding full graph snapshots.' This directly identifies what the tool does and differentiates it from sibling tools like athena_gap_get or athena_gap_replay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without expanding full graph snapshots' implies this is a lightweight alternative to tools that perform heavier expansion, giving the agent clear context for when to choose it. It does not explicitly name sibling tools or provide 'when not to use' rules, but the contrast is clear enough to guide selection without confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key side effect ('P3 mints append-only Immortal title records') and states preconditions for each tier. However, it does not mention failure modes, reversibility, permissions, or the full scope of side effects for P4/P5, leaving important behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action and tier definitions. Each sentence earns its place: action, requirements, and a notable side effect. No wasted words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (12 parameters, no output schema, no annotations), and the description covers only the tier-selection logic and one side effect. It does not explain return values, how to obtain verification_id or completion_id, the meaning of verifier_coordinate, or the role of optional parameters, so the description is not complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to several parameters: target_proof_tier (P3/P4/P5), witness_refs (attack witnesses), generalization_ref and downstream_reuse_refs (P5 requirement), and verifier_id (different active verifier). But with 0% schema coverage, it leaves verification_id, completion_id, verifier_coordinate, immortal_title, party_immortal_title, and remote unexplained, creating gaps for half the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Upgrade a completion through independent P3, adversarial P4, or crystallized/reused P5 verification.' It defines the resource (completion) and the verb (upgrade), and the tier details distinguish it from sibling tools like athena_impossible_open or athena_impossible_complete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites for each verification tier: 'P3+ requires a different active verifier; P4 requires at least five attack witnesses; P5 requires generalization plus downstream reuse.' This gives clear context on when each mode is valid, though it doesn't explicitly mention alternative tools or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses the contents of the receipt but does not state whether the operation is read-only, how it behaves if run_id is invalid, or any side effects. The 'Fetch' verb implies a safe read, but this is not made explicit, and no error or response format details are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. Every component adds value—specifying the resource, its persistence, and the detailed contents. It is front-loaded with the primary action and efficiently lists the receipt components.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one param, no output schema), and the description lists the receipt contents, which is useful. However, it does not explain what a RAGRUN receipt is, how to obtain a run_id, or any failure behavior. For an agent in this complex domain, this leaves some ambiguity but remains minimally workable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the single parameter run_id is not mentioned in the description. The description does not explain how run_id maps to a receipt, what format it should be, or any constraints beyond the schema's basic type/minLength. The description fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('one persisted RAGRUN receipt') and enumerates the exact contents (query/candidate/EQ input, selected sources, coverage, solver/optimality, decision digest). This clearly distinguishes it from sibling retrieval tools like athena_retrieval_compile or athena_retrieval_recent, which imply other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving a single receipt by its persisted nature and exact contents, but it does not explicitly state when to choose this over alternatives like athena_retrieval_recent or athena_retrieval_replay. It provides clear context (it's a get-by-id fetch) but lacks exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It explains the core behavior (recompile from frozen inputs and compare) and what is compared, but it does not disclose whether the operation is read-only, whether it modifies state, or any permission or error behavior. This is a clear gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every phrase contributes meaning, listing both the action and the specific comparison outputs, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description provides a solid overview of the operation and expected outputs. It mentions the comparison dimensions and equivalence report, though it lacks explicit return structure and side-effect clarity, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With one parameter (run_id) and 0% schema description coverage, the description must compensate for the schema's silence. It does add meaning by linking the parameter to 'one stored RAGRUN', but it does not explain the ID format, how to obtain it, or any constraints beyond the schema's minLength.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Recompile') and identifies a clear resource ('stored RAGRUN') with precise outputs (decision digest, selected sources, coverage, equivalence report). It distinguishes itself from sibling tools like athena_retrieval_get or athena_retrieval_recent by emphasizing frozen-input replay and comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for replaying a stored run to verify or compare results, but it does not explicitly state when to use this tool versus alternatives such as retrieval_get, retrieval_recent, or other replay tools. No exclusions or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses that the tool computes a SHA-256 hash and detects mutations, but it does not state whether it is read-only, what side effects occur, or what the return behavior is on mismatch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words, front-loading the primary action. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description captures the core purpose but omits parameter semantics and return behavior. With no output schema, the agent is left guessing what the tool returns, making the description incomplete for fully autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for the two parameters. It provides no direct explanation of 'envelope_id' or 'visible_text', though 'visible-byte SHA-256' hints at the role of visible_text. The agent must infer parameter meanings from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Verify an ENV emission') and explains its mechanism (recomputing SHA-256) and goal (detecting mutations). It distinguishes itself from sibling tools like athena_crystallize_output or athena_finalize_output by focusing on verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used after crystallization to check for mutations, providing clear context. However, it does not explicitly name alternatives or state when not to use it, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation via 'Return' and adds the 'live' qualifier, but it does not elaborate on potential costs, failure modes, or what 'head state' entails. With no annotations, the description carries the full transparency burden and is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action verb 'Return' and states the resource and purpose. Every word 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description names the return content (substrate counts and head state) and the purpose, which is adequate for a simple, parameterless tool. However, the lack of an output schema means the agent cannot know the exact structure of the returned data, though the description partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so schema coverage is trivially 100%. There is nothing for the description to add about parameter semantics, so the zero-parameter baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Return live substrate counts and head state', providing a specific verb and resource. It is distinct from many sibling tools that focus on other operations, though it does not explicitly name alternatives or contrast with similar observe-type tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for regression/telemetry' provides clear context on when to use this tool. It does not include exclusions or explicitly point to alternatives, but for a simple read-only retrieval tool, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 it's heuristic and for hypothesis generation only, but fails to mention output format, side effects, determinism, or data assumptions. The description adds some behavioral context but not enough for a complex computational tool, though 'discover' suggests a read-only computation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, immediately states the core action and scope. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 leaves out return value expectations and data requirements. It covers the algorithm's nature and scope but is insufficient for a causal discovery tool with nuanced parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It indirectly explains 'max_conditioning' and 'association_threshold' via 'marginal/one-variable partial-correlation thresholds', but does not define 'samples' or 'variables' beyond what the schema shows. Partial compensation but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Generate' and specific outcome: 'heuristic observational association skeleton and candidate v-structures'. Differentiates from siblings by explicitly noting 'marginal/one-variable partial-correlation thresholds' and 'Hypothesis generation only', which indicates a simplified exploratory algorithm distinct from full PC/FCI/PAG discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that this is for hypothesis generation only, implying it should be used early in analysis and not for confirmatory causal estimates. However, it does not explicitly name alternative tools or state when not to use it beyond 'only'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states the tool is 'advisory' and 'deterministic', and details what it does NOT do (never creates claims, assignments, party membership, or truth authority). This goes beyond the schema and sets clear expectations for a side-effect-free operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence packs the core functionality and influencing factors, while the second explicitly disclaims side effects. Every clause adds value, making it efficient and well-structured for an expert agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, lack of annotations, no output schema, and 4 parameters, the description should explain the return format and parameter usage. It only covers purpose and non-mutation, leaving critical invocation details (e.g., what does 'advisory' output look like, how are parameters interpreted) unspecified. This is incomplete for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It only hints at 'need_id' via 'one active NEED', but completely omits semantics for 'limit', 'remote', and 'shared_remote_mode'. The enum and bounds in the schema provide no meaningful usage context, leaving the agent without guidance on how these parameters affect matchmaking.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'advisory deterministic matchmaking' for an active need, using explicit offer envelopes and various fit factors. It distinguishes itself from sibling tools by explicitly noting it never creates claims, assignments, or party membership, making its non-mutating scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use the tool: when advisory, non-mutating matchmaking is needed. The negative constraints (never creates claims, assignments, etc.) provide clear when-not guidance. However, it does not explicitly name alternative tools (e.g., athena_cohesion_request_offer or athena_party_form) that do create these artifacts, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses key behaviors: evidence gating, UNKNOWN for weak/ambiguous matching, and the descriptive-only nature of results. However, it omits side effects, output structure, or any operational constraints such as required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler, front-loaded with the core purpose. The dense terminology may reduce readability, but every phrase adds information and the description is not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description conveys essential semantic caveats for a complex tool with a nested schema and no output schema, but it fails to explain the return format, matching mechanics, or the roles of several parameters. It is adequate for a high-level understanding but leaves notable gaps for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explicit parameter guidance. It alludes to solo_samples/party_samples via 'SOLO versus PARTY mission samples' and decision_rule via 'supplied predeclared rule', but leaves comparison_id, observer_id, and remote unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an evidence-gated matched descriptive comparison between SOLO and PARTY mission samples under a predeclared rule. It distinguishes itself from causal inference siblings by explicitly stating it is not a causal effect claim or promotion witness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use: when a descriptive, evidence-gated comparison under a predeclared rule is needed, with weak matches returning UNKNOWN. It explicitly states what it is not, but does not name alternative sibling tools or provide an explicit 'when not to use' beyond those exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does add value by noting that it avoids expanding full state, implying a lightweight read operation. However, it doesn't explicitly state read-only behavior, permissions, or return format details, which would be expected given the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with a clear verb-first structure. It is front-loaded and every word adds meaning: lists recent runs, specifies status types, and clarifies that full state is not expanded. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description covers the key aspects: what is listed, the status values, and the scope. It lacks ordering/pagination details, but these are not critical for such a simple operation. It could mention what 'recent' means, but overall it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'limit' parameter at all. Although the parameter name and constraints are self-explanatory, the description fails to compensate for the lack of schema documentation. It could have stated that 'limit' caps the number of returned runs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('recent CYCLE.1 runs'), and the output scope ('typed ACTIVE/WAITING/COMPLETE status without expanding full state'). This distinguishes it from sibling tools like athena_cycle_state or athena_cycle_replay, which likely provide full state or replay behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you need a lightweight list of recent runs and their statuses, specifically without full state. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It explicitly states that starting only creates state and does not claim later phases, which is a valuable and non-obvious side effect. This exceeds the bare minimum, though it omits details like idempotency or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and contains no filler. Every clause serves a purpose, including the caveat about state creation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex schema (4 parameters, nested objects, no output schema) and no annotations, the description is too sparse to be complete. It does not explain what the task_ref should reference, the structure of the config, or what happens after the run starts. The brief caveat provides some context but does not fill the gaps for a tool this complex.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It mentions 'task seed' and 'explicit phase configuration,' which loosely maps to 'seed' and 'config,' but leaves 'task_ref' and 'actor' unexplained. The mapping is indirect and incomplete for the required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Start') and resource ('persisted ATHENA.CYCLE.1 whole-organism run'), and clarifies the input sources ('task seed and explicit phase configuration'). It clearly distinguishes this from sibling cycle tools like athena_cycle_advance or athena_cycle_state by focusing on the initialization action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool starts a persisted cycle run. It also includes an implicit exclusion by noting that it 'does not claim later semantic phases executed,' which helps avoid confusion with phase-advancing tools, though it does not explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses key behaviors: fails closed, does not contact infrastructure, does not resolve secrets, and does not move traffic. This is valuable beyond the schema. It doesn't explain success/failure outputs, but the core safety-relevant behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action, no filler. Every word adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a validation tool with a single nested object parameter and no output schema, the description leaves the bundle structure undefined and never states what the validation result looks like. Given the opaque sibling set, the description is not sufficient for a new agent to construct a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one 'bundle' object with 0% description coverage. The description references 'BUNDLE.2 intent' but never defines what the bundle object must contain or what 'intent' means. The agent cannot infer parameter semantics from this description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('fail-closed validation'), a specific resource ('ATHENA.DEPLOYMENT.BUNDLE.2 intent'), and scopes it clearly ('without contacting infrastructure, resolving secrets, or moving traffic'). This distinguishes it from sibling deployment tools like assess_canary or verify_receipt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this is a safe validation that does not touch infrastructure, so an agent can infer to use it before performing side-effectful validation or deployment steps. However, it does not explicitly name alternative tools or state when not to use it, so it earns a 4 not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals a key rule: EQUIVALENT requires witnessed sameness across every preservation dimension, and contradictory heads become CONFLICT. However, it does not mention side effects (e.g., overwriting existing relations), permissions, reversibility, or return behavior, leaving significant gaps for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences—yet packs essential meaning: the action, the relation types, the context, and a critical constraint. There is no fluff 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (8 parameters, nested objects, no output schema, no annotations), the description provides a solid high-level overview but omits important operational details such as what happens on success, how 'same' vs 'different' exactly structure the input, and what 'CONFLICT' means in terms of stored state. It is adequate for a rough understanding but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining semantic roles: 'unordered pair' maps to left_id/right_id, 'declared dedup context' to context_id, 'witnessed sameness' to witness, and 'preservation dimensions' to the 'same' object's required fields. It does not explicitly name 'actor' or 'different', but the overall semantics are reasonably conveyed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Record') and resource ('verified EQUIVALENT or DISTINCT relation for an unordered pair in a declared dedup context'). It distinguishes itself from siblings like athena_equivalence_state (query) and athena_equivalence_resolve_conflict (conflict handling) by focusing on the recording action and the specific relation types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: when needing to record a verified equivalence or distinct relation in a dedup context. However, it does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or prerequisites. The 'declared dedup context' hints at a precondition but is not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool mutates by appending an event, enforces a precondition (fresh replay READY), and guarantees no creation/deletion. However, it does not describe failure modes, return values, or behavior when the claim is missing or the precondition is unmet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs essential information: the action, the resource, the condition, and the safety constraint. Every word earns its place; no filler or redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 params, no annotations, no output schema), the description is insufficient. It does not explain what the expected_* parameters are for, what 'fixed-path provider claim' means, what happens after appending, or what the return value indicates. Users would need external knowledge to safely invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool has 12 parameters. The description adds no explicit meaning to any parameter. While names like 'expected_source_head' hint at verification digests, the description fails to explain their role or relationships, making parameter selection and validation difficult.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: observe an existing fixed-path provider claim and append only its missing CLAIM_ACQUIRED event. It distinguishes itself from sibling tools by explicitly stating 'never create or delete the claim', which contrasts with creation-focused tools like athena_frontier_claim.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear condition for use ('when fresh replay remains READY') and an explicit exclusion ('never create or delete the claim'). However, it does not name alternative tools for creation/deletion, leaving some ambiguity about which sibling to use in those cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It does disclose critical non-obvious behavior: the refusal condition and the fact that the receipt is only game/provenance state, never canonical truth or global XP authority. This adds significant transparency beyond the schema, though it omits details about side effects, required authorization, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero filler. It front-loads the core action ('Record'), immediately specifies the resource, and then adds the critical refusal condition and a caveat about the receipt's epistemic status. Every clause earns its place, and the structure is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 20 parameters, 14 required, nested objects, and no output schema, the description stays at a high level. It gives the essential gating condition but does not explain how to construct the completion record, what values are expected for fields like transformation_class, how witnesses relate to the completion, or what a successful response looks like (since there is no output schema, the description should cover return value semantics). An agent given only this description would likely need additional guidance to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 20 parameters with 0% schema-description coverage. The description mentions 'ΩA achievement coordinate, witnesses, score inputs, and verified cleanup', which loosely maps to agent_coordinate, witness_refs, score_dimensions, cleanup_status, and unknown_residue, but it does not clarify the meaning or constraints of the many other required parameters such as completion_id, baseline, transformation_class, decisive_move, invariant, or proof_tier. Since the schema itself provides only enums and type constraints, the description fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Record') and a specific resource ('demonstrated/replayed Impossible Challenge completion'), listing key components (ΩA achievement coordinate, witnesses, score inputs, verified cleanup). This clearly identifies the tool's purpose and distinguishes it from sibling tools like athena_impossible_open or athena_impossible_verify, which focus on opening or verifying challenges rather than recording completions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states clear pre-conditions for successful use: COMPLETED is refused unless cleanup is VERIFIED and unknown_residue is zero. This tells the agent when the tool will succeed. However, it does not explicitly compare against alternatives such as athena_impossible_state or athena_impossible_verify, so it lacks explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the computation method ('exact moments, lower-tail Normal CVaR, cost and Pareto preservation'), the failure behavior ('Unknown coefficient coordinates fail closed'), and the side-effect constraint ('PLAN_ONLY'). This is substantive, though it does not describe return format or other potential 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: three short sentences with no filler. The first sentence states the core functionality, the second adds failure behavior, and the third flags plan-only mode. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 7 parameters, no annotations, and no output schema, yet the description gives only a terse summary. It omits return values, parameter format expectations, relationships to sibling tools, and any operational caveats beyond 'fail closed' and 'PLAN_ONLY.' The description is not sufficient for an agent to confidently invoke the tool in varied contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not explicitly define any of the 7 parameters. It indirectly hints at 'cvar_alpha' via 'lower-tail Normal CVaR' and 'cost_weight' via 'cost', but leaves 'variables', 'mean', 'covariance', 'actions', and 'risk_weight' without added semantic meaning beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'Rank' and identifies the target resource as 'unique linear actions under a declared multivariate Gaussian belief.' It further specifies the method ('exact moments, lower-tail Normal CVaR, cost and Pareto preservation'), which clearly differentiates this tool from sibling tools like athena_joint_gaussian_update or athena_gaussian_belief_observe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when you have a declared multivariate Gaussian belief and need to rank linear actions. The 'PLAN_ONLY' directive clarifies that it is for planning, not execution, but it does not explicitly name alternative tools or provide exclusionary guidance, preventing a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does an excellent job: it reveals the fresh-fetch-before-push, non-force push constraint, ancestor requirement, and post-push verification. This goes beyond basic 'publish' wording. It doesn't mention failure behavior or permissions, but the core safety guarantees are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with every clause contributing meaningful information (fresh-fetch, exact clean HEAD, non-force push, ancestor condition, post-push verification). No filler, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a git-publish operation with minimal schema and no annotations, the description covers the key behaviors and constraints well. It lacks parameter explanations and return-value info, but the core operation is thoroughly described. The missing 'remote' parameter explanation is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'HEAD' but never maps it to 'expected_git_head', and the optional 'remote' parameter is entirely absent from the description. The parameters are left to inference, which is inadequate given no schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('publish') with a resource ('local prompt-brain HEAD') and method ('ordinary non-force push'), plus precise conditions (ancestor check, post-push equality verification). This clearly distinguishes it from sibling prompt tools like athena_prompt_sync or athena_prompt_promote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying safety constraints (only push when remote is ancestor, verify after push), but it never explicitly says when to prefer this tool over alternatives or when not to use it. No sibling tools are named as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavior disclosure. It clearly states the fetch action, the fast-forward precondition (clean branch, local HEAD is ancestor), and the hold conditions (failed fetch, ahead, diverged, dirty). This is far more transparent than typical tool descriptions and covers the main safety-related behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single, dense sentence that front-loads the core action and packs in the preconditions and hold states. Every clause adds meaningful information without redundancy, making it efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the operational conditions well but omits any information about return values or result semantics. Since there is no output schema and no annotations, the agent does not know what the tool returns on success or in the hold states. The parameter semantics gap further reduces completeness for a tool with non-trivial behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional 'remote' parameter (string), but the description never mentions it. With 0% schema description coverage, the agent has no hint whether 'remote' is a name like 'origin', a URL, or something else, nor what happens when it is omitted. The description does not compensate for this lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is highly specific: it names the action (fresh-fetch), the resource (shared prompt-brain remote), and the exact condition under which it fast-forwards (clean branch, local HEAD ancestor). This clearly distinguishes it from sibling tools like athena_prompt_remote_status, athena_prompt_freshness, and athena_prompt_hydrate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a synchronization point for updating the local prompt brain, but it does not explicitly state when to prefer this tool over alternatives or provide exclusions. The conditional behavior ('Failed fetch, ahead, diverged or dirty states hold') gives clear context for when the tool will not complete, but no direct guidance on selecting this over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does the heavy lifting. It explains the computation source (frozen source contract and Ω snapshot) and the verification semantics. However, it does not explicitly state whether the operation is read-only, what it returns on success/failure, or any side effects, which is a meaningful gap for a tool with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the main action and follows with a concise scope clarification, making it both efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter verification tool, it covers the core purpose and a key non-goal. However, since there is no output schema, the description should clarify what a verification outcome looks like (e.g., boolean, report, error), and it does not define internal terms like 'RECONRUN' or 'Ω snapshot' that an agent may need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter run_id. The description implies run_id identifies the RECONRUN to verify, but it does not explain how to obtain it, its format, or its relationship to the frozen source contract. Some meaning is added, but not enough to fully compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Recompute') and resource ('one RECONRUN digest'), and clearly states the tool verifies receipt integrity, not freshness of current state. This distinguishes it from sibling tools like athena_reconstruction_get or athena_rehydration_verify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly indicates when to use the tool: for verifying receipt integrity of a RECONRUN. It also provides an explicit exclusion: 'not freshness of current state.' However, it does not name alternative tools or provide detailed when-not-to-use guidance beyond this single exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses the fresh-sync, replay, and verification steps, and importantly explains the meaning of PASS as shared-current causal-integrity evidence, not world truth. However, it omits side effects of the fresh-sync and failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and each sentence adds value. The caveat about PASS is a meaningful addition, not filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers the main action and interpretation of results. It lacks details on return format and when to use, but is reasonably complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain loop_id. It references 'current persisted loop chain' but does not explicitly state that loop_id identifies that chain. The parameter semantics remain ambiguous, leaving the agent to infer from the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs and resources: 'Fresh-sync the shared Git branch, then replay and verify...' It clearly distinguishes this verify operation from sibling rehydration tools like start/advance/resume. It also clarifies what PASS means, adding purpose precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a rehydration verification workflow but does not explicitly state when to use this tool vs. alternatives such as rehydration_advance or rehydration_resume. No exclusions or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that the operation returns exact navigation, versions, graph edges, and station data, suggesting a read-only behavior, but it never explicitly states that there are no side effects, permissions, or failure modes. This is useful but incomplete behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One tight sentence, front-loaded with the verb and object, and every phrase adds meaningful detail about input and output. No filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description should fully describe return values; it lists categories but does not specify their structure, nesting, or possible failure behavior. The single-parameter input is well-covered, but the output side is only partially specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero schema description coverage, the description compensates by explaining that 'identifier' can be a canonical OID, CID, or name. This adds real semantic meaning beyond the raw string property in the schema, though it omits format examples or normalization details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific action ('Resolve') and a specific resource type ('canonical OID/CID/name'), then enumerates exact outputs: 'navigation, versions, graph edges and KC144 station.' This is distinct from sibling tools like athena_regime_resolve by the explicit output combination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when an agent needs to turn a canonical identifier into navigation, versions, graph edges, or station data, but it provides no exclusions or comparisons to sibling resolution/navigation tools. It gives context without explicit when-to-use/when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavior disclosure. It clearly states 'simulate-only; never commits topology,' which is a strong side-effect guarantee. However, it does not describe what the tool returns (e.g., uncertainty bands, trajectories) or any other behavioral nuances, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary action and key constraints. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, no output schema, and no annotations, the description is too sparse. It lacks any mention of expected inputs/outputs, parameter semantics, or the structure of uncertainty-banded results. While it states a core behavioral guarantee, it does not provide enough context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all six parameters. It only hints at 'explicit context transitions,' which loosely relates to `trajectories` or `initial_context`, but provides no explanation of `regime`, `discount`, `max_steps`, or `exploration_alpha`. This is minimal added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Run uncertainty-banded multi-step organization rollouts') with a distinct resource and methodology ('explicit context transitions only'). It distinguishes itself from siblings like athena_rollout_learned and athena_counterfactual_simulate by emphasizing uncertainty banding and the 'simulate-only' nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: 'explicit context transitions only' and 'Always simulate-only; never commits topology.' This provides a when-not condition (don't use if you need to commit topology changes) but does not explicitly name alternative tools, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses important behavioral traits: it is a 'recoverable saga, not an atomic cross-store transaction', and it optionally checkpoint Git by expected-head CAS. This informs the agent about non-atomicity and recovery capabilities, which is significant context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, with the primary action first. The second sentence adds essential context about the saga nature. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 7 parameters and no output schema, the description is somewhat terse. It provides the key saga context and preconditions but omits details like return values, error handling, or the meaning of dry_run/actor parameters. Overall, it gives a high-level understanding but lacks completeness for full autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'expected-head CAS' and 'topology+semantic CAS preflight', which gives hints about parameters like expected_git_head, expected_topology_version, and expected_semantic_eid, but it does not explicitly explain individual parameters or their roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Apply'), the target ('topology projection to canonical JSPACE'), and the precondition ('after topology+semantic CAS preflight'). This clearly distinguishes it from sibling tools like athena_projection_prepare or athena_topology_apply by emphasizing the 'prepared' projection and post-preflight step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'after topology+semantic CAS preflight' implies when to use this tool, suggesting a specific sequence. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of clear usage guidelines with exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite lacking annotations, the description discloses key behavioral traits: it advances through real internal phases, stops at typed WAITING_* states, and does not simulate. This goes beyond a generic 'advance' and informs the agent of the tool's limits. However, it does not mention return value, error handling, or the exact meaning of 'CYCLE.1', leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action verb. No filler or redundancy; every phrase (e.g., 'real internal phases', 'WAITING_* state') adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description covers the core operation but omits important context: the effect of max_steps, what the tool returns, and prerequisites or error conditions. It also uses the cryptic 'CYCLE.1' without explanation, making it incomplete for a complex stateful operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It maps 'inputs' to 'newly supplied witnessed inputs' but leaves cycle_id implicit via 'CYCLE.1' and says nothing about max_steps. With 3 parameters, only one is partially explained, so the compensation is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool advances a cycle (verb+resource) and specifies it merges newly supplied witnessed inputs. The phrase 'through as many real internal phases as possible' and the stopping condition distinguish it from cycle_start and cycle_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies when to use it: when you have new witnessed inputs to merge and want to advance a cycle as far as possible. It also explicitly states it does NOT simulate measurements, execution, or tests, providing a clear when-not. While it does not name sibling alternatives, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that PASS only verifies supplied packet bytes and does not perform live cluster observation, authority verification, cutover, or activation receipt actions, preventing misuse. It does not mention side effects or error behavior, but for a verification tool that is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at two sentences, front-loaded with the main action ('Replay...'), and each sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters and no output schema, the description gives a solid high-level purpose and boundaries, but lacks details on failure behavior and the specific meaning of each expected binding. It is adequate for basic understanding but not fully complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It introduces the concept of 'exact expected bindings' which groups all expected_* parameters, and 'supplied packet bytes' for the packet field. However, it does not explain any individual parameter's meaning, leaving cryptic names like expected_canary_witness_digest and expected_quiescence_assessment_digest unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool replays a specific packet type against exact expected bindings, and explicitly lists what it is not (current cluster observation, authority verification, cutover, activation receipt), distinguishing it from sibling deployment-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The negative clauses provide useful guidance on when not to use this tool (not for live observation, authority checks, etc.), implying it is for offline packet verification. However, it does not explicitly name alternative sibling tools, so the guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers meaningful behavioral context: 'Failure creates evidence; it does not fabricate output.' This signals that the tool records a failure event as evidence rather than inventing a successful result, which is valuable for an agent selecting the tool. It also implies the 'witnessed' aspect verifies authenticity, though it does not enumerate all side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no superfluous words. It front-loads the core purpose and adds a single critical behavioral note, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple failure-recording tool but leaves gaps due to the lack of annotations, output schema, and parameter elaboration. It does not clarify the return behavior, the requirement that witness.verified must be true (though visible in the schema), or any potential side effects beyond 'creates evidence'. While the schema covers some structured details, the description does not add enough to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only hints at 'reason' and 'witnessed' but does not explain the parameters task_id, actor, or the structure of the witness object (including the verified field that must be true). With 0% schema description coverage, the description fails to compensate for the missing parameter semantics, leaving the agent dependent solely on the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Record') and a specific resource ('witnessed extraction-task failure'), which directly conveys the tool's purpose. It also differentiates from sibling tools by emphasizing 'failure' and adds a key behavioral trait ('does not fabricate output'), further distinguishing it from tools that might generate or complete results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: when a witnessed extraction task fails with an explicit reason. It provides clear context for when to invoke the tool. However, it does not explicitly mention when not to use it or name alternative tools, so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of indicating safety; it does so by leading with 'Read', signaling a non-mutating operation. It also discloses the scope of returned data. However, it does not elaborate on prerequisites beyond 'registered' or failure modes, but the read-only nature is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the main verb and object ('Read one registered HUG implementation'), followed by a compact list of content. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool, the description adequately lists the categories of information returned (six-parameter semantics, schemas, maturity, witness routes). The absence of an output schema is mitigated by enumerating content areas, though error behavior and exact response structure remain unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter impl_id is not documented in the schema (0% coverage). The description implies that impl_id identifies a registered HUG implementation, providing some context, but it does not specify the format, expected value types, or how to obtain valid IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a read operation for a single registered HUG implementation and enumerates specific content areas: exact six-parameter semantics, schemas, maturity, and witness routes. This distinguishes it from sibling tools by emphasizing 'one' and the detailed nature of the data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing detailed information for a specific HUG implementation ('Read one registered HUG implementation'), but it does not explicitly state when to prefer this over siblings like athena_hug_list or athena_hug_invocation, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It indicates a read-only operation ('Fetch') and adds meaningful context about the returned object's contents ('frozen input/output', 'branch lifecycle', etc.), suggesting immutability and what data is included. However, it does not explicitly state error behavior or access requirements, so a small gap remains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and core noun. It is concise and includes relevant details without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with one parameter and no output schema, the description provides a good overview of what the tool returns by listing key components. It is not exhaustive about response structure or possible errors, but given the simplicity, it is sufficiently complete for an agent to understand the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (run_id) with 0% description coverage, so the description must compensate. While it does not explicitly explain run_id, the phrase 'Fetch one persisted AORRUN' implies the parameter identifies the specific run. The tool name and obvious parameter name provide some meaning, but the description could be more direct in linking run_id to the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and identifies the resource as 'one persisted AORRUN', clearly indicating a single-object retrieval. It further distinguishes this from sibling tools like athena_orchestration_recent or athena_orchestration_replay by emphasizing 'persisted' and listing specific content aspects (frozen input/output, branch lifecycle, authority snapshots, decision digest).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to fetch a specific run by its persisted ID, but it does not explicitly state when to use it over alternatives such as athena_orchestration_recent or athena_orchestration_replay. There is no direct comparison or exclusionary guidance, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses key behavioral traits: messages must be acknowledged to contribute to party XP, posting itself earns zero XP, and messages are tagged with party_id and goal_refs. This adds meaningful context beyond the schema, though it omits details like auth requirements, side effects on existing messages, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It leads with the primary action, then provides essential behavioral context about XP eligibility and goal tagging. Every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no output schema, and no annotations, the description gives a good high-level purpose but leaves several gaps: no return value information, no explanation of the acknowledgement/reward window mechanics, no prerequisites (e.g., valid party_id), and incomplete parameter semantics. It is adequate but not fully complete for an agent to invoke confidently without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains party_id and goal_refs ('tagged with party_id and explicit party goal refs'), but leaves sender, recipients, message, remote, reply_to, and message_kind unexplained. The message_kind enum values are not described, and no guidance is given on how these parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Post'), the resource ('party-scoped coordination message'), and the mechanism ('canonical Message Board V1'). It distinguishes this tool from generic messaging by emphasizing party_id and goal_refs, and clarifies the XP contribution rule, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: posting party-scoped coordination messages that need goal refs and potential XP eligibility. It does not explicitly name alternatives (e.g., athena_message_board) or state when not to use it, but the context is specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly states a read-only behavior ('Return'), implying no side effects. It also adds context about the scope ('globally visible') and the selection criterion ('not adopted'). While it doesn't discuss auth or error cases, for a simple query tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence (8 words) that front-loads the primary verb and resource. Every word adds value, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema, no annotations), the description provides a complete functional understanding. It explains what the tool returns and the scope. Minor gaps include lack of usage guidance and parameter explanation, but these are not critical for such a straightforward query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description indirectly references the single required parameter 'agent' via 'this agent', giving some meaning beyond the raw schema. However, it does not explicitly explain the parameter's format, allowed values, or why it is required. With 0% schema description coverage, the description partially compensates but leaves room for clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and a clear resource ('globally visible mutations this agent has not adopted'). It distinguishes itself from sibling tools like athena_adopt_mutation or athena_promote_mutation by explicitly targeting unadopted mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking which mutations are pending for a given agent, but it does not explicitly state when to use it versus alternatives or provide exclusions. There are no references to sibling tools or conditions that would help an agent decide between this and other mutation-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Fetch' and 'frozen' signal a read-only, immutable snapshot. It also discloses the specific contents: source sets, Ω snapshot, defects, and digest. It does not mention error handling or absence behavior, but for a simple get this is reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, 15 words, front-loaded with the verb and resource. It lists the key return elements without extraneous detail. Every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter fetch tool with no output schema, the description adequately conveys what the agent will get. It lists the data categories, and 'one' makes it clear this is a single-object retrieval. Minor gaps like error behavior or pagination are not critical here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It does not explicitly elaborate on run_id, but the parameter name is self-explanatory and the description clarifies that the entity is a RECONRUN. This adds some meaning beyond the schema, though not deeply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch'), names the resource ('frozen RECONRUN'), and enumerates the exact components returned. This clearly distinguishes it from sibling tools like athena_reconstruction_recent (which lists runs) and athena_reconstruction_verify (which likely checks correctness).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: pass a run_id to get a single reconstruction run. However, the description does not explicitly contrast with alternatives or state when not to use it. With many sibling tools, a sentence like 'Use for retrieving one specific run; use recent for listing' would be clearer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so richly. It reveals that present measurements must be witnessed, missing required measurements become UNKNOWN, selection is coverage-aware/budgeted/EQ1-safe/replayable, and the tool does not claim to have searched sources it was not given. This goes well beyond a basic functional statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three dense sentences with no wasted words. It front-loads the core purpose, then adds behavioral constraints and a caveat. Every sentence contributes new information, making it appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is highly complex with 8 parameters, nested objects, no output schema, and no annotations. While the description covers high-level behavior and edge cases (missing measurements, replayability), it omits critical details such as return values, error conditions, and any parameter-specific explanations. The description is decent but incomplete for the complexity involved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the 8 parameters and nested objects. However, it only vaguely references 'persist' and 'candidates' without explaining any parameter specifics, such as query_ref, query structure, eq_snapshot, or equivalence_context. The description fails to add meaningful per-parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Compile and optionally persist a RAG.1 decision over supplied provenance candidates.' This is a specific verb+resource construction that distinguishes it from sibling tools like athena_retrieval_get, athena_retrieval_recent, and athena_retrieval_replay. The scope is well-defined: it operates on supplied candidates, not on retrieval itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied through phrases like 'over supplied provenance candidates' and 'does not claim it searched sources it was not given,' which suggest using this tool when candidates are already available rather than for search. However, no explicit 'use when' or 'instead of X' guidance is provided, and no alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It adds valuable behavioral traits: the plan is 'non-destructive' and the warning that 'a future/newer DB schema blocks silent downgrade' discloses a key constraint. This goes beyond the basic function description, though it could mention error behavior or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences, each carrying meaningful content. The primary action is front-loaded, and the warning about downgrade adds crucial context without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema or annotations, the description adequately explains the tool's purpose and an important safety caveat. However, it does not describe the structure of the returned migration plan, which would improve completeness given no output schema is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4 per the rubric. The description adds context about the migration plan's purpose but does not need to describe parameter semantics since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('Return'), a defined resource ('non-destructive migration plan'), and a clear scope ('from current schema-ledger version to this runtime target'). It distinguishes itself from sibling tools like athena_schema_migrate (execution) and athena_schema_status (status) by focusing on planning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. The 'non-destructive' hint implies it is for safe planning, but no direct comparison or exclusion (e.g., 'use this instead of athena_schema_migrate to preview changes') is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It adds meaningful context ('frozen inputs', 'proves adapter determinism') and an important caveat, but it omits side effects, error behavior, or what the return payload looks like, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences, front-loaded with the active verb, no filler. The second sentence adds a valuable conceptual caveat that prevents misuse, so every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no annotations and no output schema, the description is nearly complete: it states the action, the resource, the verification objective, and a key epistemic limitation. It doesn't spell out the exact return format or failure modes, but those are secondary for this simple replay operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides run_id as a string with no description. The description hints that run_id identifies a 'persisted typed transport' with frozen inputs, adding some meaning, but it never explicitly names run_id or explains how to obtain/validate it. With 0% schema coverage, this is partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Replay') and names the resource ('one persisted typed transport') plus the intended check ('verify transport digest'). It clearly differentiates this from sibling transport/replay tools by focusing on typed transports and digest verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful usage context: replay proves adapter determinism and not semantic truth, which tells the agent when this tool is relevant and what it cannot establish. It does not explicitly name alternatives, but the boundary it draws is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavior: assumption-incompatible or inconclusive values return HOLD, and notes version stability (V2 does not change V1 semantics). It does not describe the return format for conclusive values or whether the tool has side effects, but 'Evaluate' suggests a read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and immediately followed by behavioral semantics. No superfluous words or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should cover expected return values and any preconditions. It specifies HOLD for certain cases but does not indicate what conclusive evaluation returns (e.g., 'pass', 'fail', a normalized measure). The parameter list is partially explained but not all param combinations or edge cases (e.g., all nulls) are addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no parameter descriptions (0% coverage), but the description labels each witness type and connects them to the parameter names (nth_term_limit, ratio_limit, root_limit, contraction_q, spectral_radius). It does not explain detailed evaluation criteria for each, but it adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates caller-supplied convergence/stability witnesses, listing the specific witness types (nth-term limit, ratio/root limit, contraction constant, spectral radius). This distinguishes it from sibling tools by specifying a precise verb (evaluate), resource (witnesses), and scope (only caller-supplied).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Evaluate only caller-supplied' implies that the tool does not compute witnesses itself, and the HOLD return for incompatible/inconclusive values gives a hint of expected behavior. However, there is no explicit guidance on when to use this tool versus alternatives, and no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose important behavioral traits: the estimates are 'assumption-scoped' and the tool 'never proves identification.' It also clarifies the supported causal strategies. It stops short of describing output details, assumptions format, or failure modes, but adds substantial context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no waste. The first sentence front-loads the action and scope, and the second provides a critical caveat. Every clause contributes necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex 8-parameter tool with no output schema and no annotations, so the description needs to be thorough. It delivers a clear purpose and a key causal caveat, but it lacks an explanation of return values, parameter-method mappings, or assumptions format. It is minimally adequate for an expert but incomplete for reliable autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for 8 parameters. It adds meaning by naming three method families, which implicitly maps to adjustment, instrument, and mediator, and by noting 'explicit numeric samples' for the samples parameter. Yet it does not explicitly explain the assumptions object, required combinations per method, or the roles of treatment/outcome/mediator/adjustment/instrument, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Estimate') and clearly identifies the resource and scope: 'linear BACKDOOR, IV-Wald, or FRONTDOOR mediation effect from explicit numeric samples.' This distinguishes it from sibling tools focused on identification, discovery, or other causal targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool (assumption-scoped estimation from numeric samples) and an explicit boundary: 'Estimation never proves identification,' which warns against using it for identification purposes. However, it does not name alternative tools or provide explicit 'use X instead' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses important non-mutating, non-authoritative behavior. It also reveals that the tool reads shared-current Message Board claims, which implies a read-only snapshot. However, it does not describe the structure of 'treatment options' or how results are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. The first sentence leads with the main action and detailed scope; the second provides clear behavioral exclusions. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 parameters and no output schema, and while the description gives a solid high-level purpose and constraints, it does not explain the output format or list of 'treatment options.' This leaves ambiguity for an agent trying to interpret results, so the description is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description only partially compensates by explaining classification dimensions like work-key/task/target collisions, JOIN/REPLICA intent, and partition evidence. Several parameters (remote, task, replication_reason, shared_remote_mode) are not addressed, leaving their semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: "Read shared-current Message Board claims and classify... into non-authoritative treatment options." It uses specific verbs (read, classify) and a specific resource, and explicitly lists what it never does, which distinguishes it from sibling cohesion tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for pre-action duplicate detection by referencing exact collisions, fuzzy warnings, and partition evidence. It also provides exclusions by stating the tool never mutates, auto-joins, assigns work, fabricates MATA semantics, or grants execution authority, but it does not name specific alternative tools or provide explicit when-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It describes the propagation mechanism and constraints (weight, hop decay, threshold, bounded radius), but it does not mention side effects, return value, or whether it mutates state. The algorithmic details add some context, but significant behavioral traits remain undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the main verb ('Propagate'), and contains no redundant wording. Every phrase adds meaning, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the core algorithm and all parameters, but it omits the output format, edge cases, and side-effect behavior. With no output schema or annotations, these missing details leave an agent uncertain about what to expect from the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It maps weight, hop decay, threshold, and bounded radius directly to the schema's edge weight, hop_decay, threshold, and max_hops. It interprets the parameters conceptually, though it does not explicitly define seeds beyond implying them as the 'failure/change alarm' origin.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool propagates a failure/change alarm over explicit influence/dependency edges, with specific algorithmic controls (weight, hop decay, threshold, bounded radius). This is a specific verb+resource+scope that distinguishes it from sibling tools like athena_graph_path or athena_dense_navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: you can use this when you need to propagate alarms along dependency edges with configurable decay/threshold/radius. The phrase 'only over explicit influence/dependency edges' sets a clear boundary, but it does not explicitly name alternatives or provide 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the registration only creates a CANDIDATE and does not assert the implementation is tested/canonical, which is a key behavioral trait. It doesn't cover side effects or return values, but the core state transition is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, each adding necessary information: the purpose, mandatory fields, and the behavioral limitation. It is front-loaded with the primary verb and resource, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and a key behavioral limitation, but it does not explain return values, error conditions, or the lifecycle of a CANDIDATE. Given the tool's complexity, 8 parameters, nested objects, and many sibling tools, more context would be needed for an agent to fully understand the implications of registration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description needs to compensate. It lists the six parameter meanings (io,au,fx,lm,er,st) and mentions algorithm ref, implementation digest, and schemas are mandatory, which adds some value. However, it does not explain what these parameters mean, leaving the agent without sufficient semantic grounding for invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Register an exact HUG implementation identity,' which clearly specifies the verb (register) and the resource (implementation identity). It also distinguishes itself from related tools by stating 'Registration creates CANDIDATE only; it does not assert semantic QHUG is tested/canonical,' contrasting with promotes/verification tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: all six parameter meanings and other fields are mandatory, and it notes the tool only creates a candidate. However, it does not explicitly name alternative tools for promotion or verification, so it lacks explicit exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of disclosing behavior. It states what the tool computes (recompute digest), what it verifies (frozen implementation/input integrity), and what it intentionally does not do (semantic replay). While it does not describe return values or side effects, the read-only nature of 'verify' and the explicit scope make the behavior reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every phrase adds distinct information. It is concise without being underspecified, delivering the core purpose and key exclusions in under 25 words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's modest complexity—one parameter, no output schema—the description covers the essential scope and limitations. The caveat about semantic replay adds necessary context for correct use within the Athena toolkit. However, the absence of any indication of the return value or success/failure behavior leaves a minor completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter, invocation_id, with 0% description coverage. The description does not explain what invocation_id refers to or how to obtain it. Although the parameter name is moderately self-explanatory, the description adds zero semantic value about the parameter, so it fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Recompute') and resource ('HUGINV packet digest'), clearly stating the tool's function. It further distinguishes the tool from siblings by narrowing its scope to 'frozen implementation/input integrity only' and explicitly excluding semantic replay, which separates it from related verification tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: to verify a frozen packet's integrity. It also provides an exclusion condition ('semantic replay is N/A unless a real registered executor replays the algorithm'), though it does not explicitly name alternative tools. This is sufficient guidance for a specialized verification action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It explicitly states that the tool 'records a scoped hard barrier and success contract' and 'grants no execution authority, XP, title, or proof standing.' This is a crucial boundary for an agent to know and is exactly the kind of nuance annotations would not capture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every clause adds value. There is no filler or redundant repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, 6 required, no annotations, and no output schema, the description is too sparse to be fully actionable. It omits return values, detailed side effects beyond the contract, and any procedural guidance for parameter population. The behavioral transparency is strong, but the overall context is incomplete for an agent to invoke the tool correctly without further reasoning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for missing parameter meanings. It only lightly glosses 'barrier' and 'success_conditions' as a contract, but leaves quest_id, opener_id, search_scope, safety_scope, remote, and title unexplained. Parameter names are not self-evident enough for all eight fields, especially 'search_scope' and 'safety_scope'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Open') and resource ('Git-shared Impossible Challenge') with a clear location ('Message Board frontier'). It is immediately distinguishable from sibling tools like athena_impossible_complete, athena_impossible_verify, and athena_impossible_state, which handle other lifecycle stages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context is provided: the opener must already be present on Message Board V1, and the tool is for recording a challenge contract. It does not explicitly name alternative tools or list when-not-to-use scenarios, but the prerequisite and purpose are clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that 'Unknown coefficient coordinates and non-finite state fail closed,' providing edge-case behavior, and states the operation is exact and finite-dimensional. It does not, however, describe return format or side effects, so a small gap remains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with three short sentences that front-load the core purpose and add edge-case and scope information. Every sentence carries meaningful content with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is mathematically complex and lacks both annotations and output schema, yet the description omits the return value and the precise structure of the observation parameter. It covers purpose, edge cases, and scope, but these gaps mean it is only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no parameter descriptions (0% coverage), so the description must compensate. It adds meaning by explaining the operation's mathematical context and the observation's linear-Gaussian nature, but it does not detail the structure of the 'observation' object or the individual roles of variables, mean, and covariance beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs an exact finite-dimensional multivariate-Gaussian posterior update for a single linear-Gaussian observation. It differentiates from general continuous Bayes by explicitly saying 'Model state only; not general continuous Bayes,' which distinguishes it from broader Bayesian tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies it is for 'one declared linear-Gaussian observation' and excludes 'general continuous Bayes,' giving clear when-to-use and when-not-to-use context. However, it does not explicitly name alternative tools or provide detailed criteria beyond this mathematical scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses key behaviors: the event is provenance-only, does not prove result truth, and earns zero XP. It also specifies membership constraints, which is substantial context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every sentence adds value: the first states the purpose, the second explains constraints and consequences. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters and no annotations, the description gives a solid overview but leaves some parameter meanings implicit (e.g., remote, witness_ref). It also does not describe return values or error behavior. While the core purpose is clear, more detail could be added for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It indirectly explains sender, goal_id, recipients, and evidence_kind (RESULT/VERIFY) via constraints and event type. However, parameters like remote, result_ref, witness_ref, and party_id receive no explicit explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool posts an 'attributable party RESULT or VERIFY provenance event through canonical Message Board V1.' This specifies the verb (post), resource (party result/verify event), and context (canonical Message Board V1), distinguishing it from general party messaging tools like athena_party_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit conditions: sender must hold the board claim, goal must be assigned, recipients must be current party members. It also notes that posting earns zero XP, implying use for provenance rather than rewards. However, no alternative tools or 'when not to use' are explicitly mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses a key limitation: caller-supplied packets can never mint QUALIFIED, only ATTESTED_READY. It also mentions optional persistence. However, it does not detail the side effects of persistence or any permissions needs, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the purpose and immediately providing the key caveat. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and the important trust boundary, but because there is no output schema and no annotations, it omits the return format and the specific effects of persistence. For a tool with nested objects and an optional write side effect, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does add meaning by referring to ci_witness and smoke_witness as 'caller-supplied packets', 'exact-head' for git_head, and 'optionally persist' for the persist field. Still, it does not explain the actor parameter or the precise persistence behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Evaluate and optionally persist PROMOTION.2 exact-head readiness.' It specifies the verb, resource, and scope. It also distinguishes from sibling tools by explaining the caller-attestation limitation and the difference between ATTESTED_READY and QUALIFIED.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when caller-supplied CI/smoke packets are available. It explicitly notes that QUALIFIED requires trusted external verification, guiding the agent away from this tool for that use case. However, it does not name specific alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 by disclosing transactional atomicity, the optimistic concurrency guard, and the recording of reversible before/after witnesses. It omits failure behavior on version mismatch or permission requirements, but it adds meaningful behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the core action and conditions. Every phrase adds value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no annotations, and a nested payload object, the description is compact but omits return value semantics and payload structure. It captures the core transactional behavior, making it usable for selection but not fully sufficient for correct invocation without additional schema hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate; it enumerates the valid operation values and explains expected_version's conditional role. However, it does not describe the payload's per-operation structure or the actor parameter, leaving a significant semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as transactionally applying specific topology mutation operations (INIT/REPLACE/FISSION/FUSE/PATCH_MODULE) to a collective topology, with a version-match guard. This distinguishes it from related sibling tools like athena_topology_get and athena_topology_rollback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a clear precondition: apply only when expected_version matches the current version, which is a strong usage signal. It does not explicitly name alternatives or exclusions, but the operational context is clear enough for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels: it discloses the prerequisite condition (bubblewrap availability), the failure mode (HERMETIC_UNAVAILABLE), and the guarantee 'Never silently falls back'. This gives the agent a clear safety profile beyond what any annotation would provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences of 24 words total, front-loaded with the primary action and then the conditional behavior. Every word earns its place; there is no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering the tool's simple purpose and lack of output schema, the description covers the key operational aspects: what it runs, the prerequisite, and the failure behavior. It does not describe return values or side effects, but for a fail-closed test runner, the provided context is sufficient. The only noticeable gap is the missing parameter guidance, which is already penalized in dimension 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention either parameter (regression_ref, timeout_s). The tool name and description imply repository testing, but the required regression_ref and optional timeout_s remain completely unexplained, forcing the agent to guess their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: 'Execute a repository unittest only when bubblewrap namespace isolation is available'. This is a specific verb-resource pair with a clear condition, distinguishing it from sibling tools like athena_witness_cell by focusing on repository unittest execution and the bubblewrap isolation requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'only when bubblewrap namespace isolation is available' provides an explicit condition for use, and 'otherwise fail closed with HERMETIC_UNAVAILABLE' tells the agent that this tool should not be used without that isolation. It does not name alternatives but clearly delimits the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses key behaviors: using the matching historical evaluator version, checking receipt determinism, and notably not re-querying the external provider. This is above-average for an MCP tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, and contains no fluff. Every clause adds meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter replay tool, the description covers purpose, key behavioral constraints, and the source of inputs. It does not describe return values or error conditions, but the tool's simplicity and lack of output schema make this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It implies that run_id identifies a stored PROMOTION.1 or PROMOTION.2 predicate, but it does not explicitly describe the parameter's provenance, format, or how to discover valid run_ids. This is partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Replay) and a specific resource (stored PROMOTION.1 or PROMOTION.2 predicate). It clearly identifies the tool's niche among many replay siblings by specifying the predicate types and historical evaluator matching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on usage: it replays a stored predicate from frozen inputs. The statement 'it does not independently re-query the external provider' gives an implicit when-not-to-use signal, but it does not name alternative tools or provide explicit comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It explicitly states 'Never mutates local history', a key safety guarantee, and mentions optional fetch which implies network behavior. Could add output format or error details, but core behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise, front-loaded sentence with no filler; every clause adds value. The main action, optional flag, and safety guarantee are all included efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-param tool with no annotations and no output schema, the description provides purpose, an optional flag, and a safety guarantee. It lacks a description of the returned status format, but this is a minor gap given the tool's name and scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description must compensate. It mentions 'optionally fetch' and 'configured remote branch' which relate to the fetch and remote parameters, but does not explicitly define the remote parameter's semantics or default behavior. Param names help, but gaps remain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Uses specific verb 'compare' with resource 'local prompt-brain checkout' and 'configured remote branch', clearly distinguishing from siblings like athena_prompt_sync. The scope is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'optionally fetch before comparison' and 'Never mutates local history', providing clear context for safe read-only inspection. Does not explicitly name alternatives, but gives enough guidance for when and when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and succeeds: it discloses the fresh-sync side effect and the hold behavior on unverified shared state. It does not fully clarify what 'holds' means (block, error, return empty) or mention any authentication requirements, but it provides meaningful behavioral context beyond the bare tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the primary action (fresh-sync then list) and specifies exactly what is in the result. Every phrase adds value, and there is no redundant or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-oriented inventory tool with no output schema, the description tells the agent what it will receive (status, step, digests, checkpoint heads) and how it behaves when state is unverified. The phrase 'unverified shared state holds' could be more explicit about the outcome, but overall it gives enough context for an agent to decide whether this tool satisfies a request for rehydration loop inventory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not explain parameter semantics. Although it describes the content of the returned list (status, step, digests, checkpoint heads), this is more about output than parameters, but with no params, baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb-resource combination: it fresh-syncs the shared Git branch and lists rehydration loops with their status, step, digests, and checkpoint heads. This distinguishes it from sibling tools like athena_rehydration_verify or athena_rehydration_advance by indicating a listing/indexing role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (to get current Git-persisted rehydration loop inventory) but does not explicitly state alternatives or exclusions. The 'Unverified shared state holds instead of returning stale inventory' line provides conditional context but does not compare to related tools such as athena_rehydration_verify.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 adds useful behavioral context by stating that additive drift is reported separately from corruption, indicating a nuanced verification result. However, it does not disclose side effects (e.g., read-only), return format, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action ('Verify schema-ledger target version') and every word adds value. It is appropriately concise without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 covers the key purpose and a key behavioral distinction. For a parameterless verification tool, it is reasonably complete, though it omits details about the exact output format or how corruption is indicated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has no parameter semantics to explain. The baseline of 4 applies because there is nothing the description needs to add beyond what the empty schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Verify' and identifies exact resources: 'schema-ledger target version' and 'critical unified-organ tables.' This clearly distinguishes it from schema manipulation tools like athena_schema_migrate and athena_schema_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool checks, which clearly implies when to use it: when schema verification is needed. However, it does not explicitly name alternatives or state when not to use it, so it lacks explicit exclusions but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses conditional persistence ('optionally persist'), the nature of the computation ('witnessed directed reachability closure'), and that it is 'navigation closure, not logical/causal entailment.' It could go further by describing return values or side effects, but it reveals the core behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences include the core formula, a semantic exclusion, and a routing hint. Every phrase adds value, and the description is front-loaded with the most important information. There is zero filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of this tool (7 parameters, nested objects, no output schema, no annotations), the description provides a good algorithmic definition but omits practical details: what does it return? What exactly does 'persist' do? How should sources and targets be structured beyond minimal schema hints? It is adequate for domain experts but incomplete for a generic agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source of parameter meaning. It maps 'frozen source groups' to sources, 'typed graph edges' to edges, 'explicit target nodes' to targets, and 'policy' to the traversal policy, plus 'optionally persist' to the persist boolean. However, it does not explain task_ref or actor, and it lacks structural details for complex params like sources and targets.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines what the tool does: 'Compile and optionally persist GAP.1' with an explicit formula ('explicit target nodes minus witnessed directed reachability closure over frozen source groups and typed graph edges'). It also distinguishes itself from other tools by stating 'This is navigation closure, not logical/causal entailment,' which separates it from causal siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives usage context by explicitly stating what it is not for ('not logical/causal entailment') and hints at follow-up behavior ('Unknown residual metrics route to measurement'). However, it does not explicitly name alternative tools or provide a clear 'when to use this tool' scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and meets it: it discloses validation ('validates registered input schema'), state freezing ('freezes implementation snapshot/context/input digest'), return status ('returns PLANNED only'), and non-execution ('does not execute or invent QHUG semantics'). This provides rich behavioral detail beyond the structured schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, with the main action front-loaded in the first sentence. Every sentence adds necessary information—requirements, behavior, and exclusions—with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core behaviors: creation, validation, freezing, return status, and non-execution. However, it does not explain the optional parameters (actor, context, required_status) or the structure of the returned packet, which would be helpful given there is no output schema. The non-execution caveat is valuable but the tool's integration with the HUGINV workflow is only partially described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It mentions the required keys 'io,au,fx,lm,er,st' but gives no meaning for them, and it does not explain optional parameters like actor, context, or required_status. The only implicit parameter hint is 'for registered implementation' referring to impl_id, leaving most parameters semantically undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create HUGINV execution packet for registered implementation', which clearly specifies the verb (Create) and resource (HUGINV execution packet). It further distinguishes from related tools by stating 'It does not execute or invent QHUG semantics', separating it from execution tools like athena_hug_invocation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: 'for registered implementation' and 'Requires exactly io,au,fx,lm,er,st' indicate prerequisites. The line 'It does not execute or invent QHUG semantics' tells the agent not to use this tool for execution, but it does not name a specific alternative, so it stops short of explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well: it declares read-only behavior, exact UTC half-open window semantics, 'already-persisted' data, and explicitly excludes higher-level analysis. This goes well beyond what the schema or annotations reveal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the primary action and scope, and every clause adds meaningful information. There is no fluff or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the input window and output record contents, which is strong given no output schema. However, it omits semantics for the optional parameters (max_records, expected_git_head) and any error/edge-case behavior, leaving some contextual gaps for a 4-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description compensates partially by specifying the 'exact half-open UTC window' for window_start/window_end, but it does not explain max_records or expected_git_head. With 4 parameters and no schema docs, this is a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads an exact half-open UTC window of persisted rehydration receipts/events and Message Board events, which is a specific verb+resource+scope. It also lists concrete return contents that distinguish it from analysis-oriented sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states what the tool does not do ('performs no assay classification, behavioral inference, causal attribution, or promotion'), giving clear context for when to use it for raw trace reads vs. analytic tools. It does not name alternative sibling tools, but the exclusions serve as practical usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly enumerates the returned pieces of data (root, branch, head, dirty state) and uses 'Return' which implies a read-only operation. Though it doesn't explicitly say 'does not modify anything', the nature of a status check makes this clear enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and action. Every word contributes to explaining the tool's purpose without any fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status tool with no output schema, the description adequately lists all returned fields. The term 'configured canonical Git brain root' is domain-specific but still clear enough within the tool's context, making the description complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the baseline for this case is 4. The description adds context about what the tool reports, which is enough since there are no inputs to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Return' with a clear resource: configured canonical Git brain root, branch, head, and dirty state. It unambiguously identifies the tool's function and naturally distinguishes it from the long list of unrelated sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating exactly what information is returned, making it evident when to use this tool. No explicit alternatives or exclusions are mentioned, but given the tool's unique purpose among siblings and zero parameters, no further guidance is necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure and does so well by explaining the empty-list meaning and explicitly warning against simulating an implementation. It implies this is a read-only listing operation, though it does not discuss potential error conditions, sorting, or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences and front-loads the essential action ('List registered HUG implementations'), followed by the optional filter and a crucial caution. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with two optional parameters and no output schema, the description covers purpose, filtering, and the empty-list interpretation. It does not describe the structure of returned items, but that is not strictly necessary for a safe list operation, making this description fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds meaning by naming the possible status values (CANDIDATE/TESTED/CANONICAL) and noting the filter is optional. The 'limit' parameter is not mentioned in text, but the schema fully specifies it as an integer between 1 and 500, so the description compensates for the most semantically important parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('registered HUG implementations'), and mentions optional filtering by status. This clearly distinguishes it from sibling tools like athena_hug_register or athena_hug_state, which handle other aspects of the HUG lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context on when to use the tool (listing registered implementations) and gives an important caveat: an empty list means no semantic implementation is registered, and the agent should not simulate one. However, it does not explicitly compare with sibling alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses advance rules and prerequisites, and mentions 'skips fail' as a behavioral trait. It does not cover reversibility or side effects, but provides meaningful operational context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Every word adds value: the action, the one-step constraint, the per-transition requirements, and the failure behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of nested parameters and no output schema, the description covers the core semantic rules (transition paths and prerequisites) and mentions failure handling. It lacks information about return values or side effects, but is sufficient for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It links target_status to the transition prerequisites (test for TESTED, canonical_authority for CANONICAL), giving meaning to the conditional parameters. It does not explicitly explain impl_id or actor, but they are straightforward identifiers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Advance') and resource ('HUG implementation') and clearly states the exact one-step progression. It distinguishes itself from sibling tools like athena_hug_fail and athena_hug_invocation by describing the promotion action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit conditions for each transition (CANDIDATE->TESTED requires witnessed test; TESTED->CANONICAL requires authorized ref) and notes 'skips fail', indicating when not to use or expected failure behavior. It does not name alternative tools, but the context is clear for when this tool applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the operation is read-only and does not silently alter mutation semantics, addressing key behavioral concerns. It does not detail the exact side effects of running optional replay samples, but the 'does not silently change' phrase partially mitigates that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that starts with the main purpose and immediately lists the readiness components and safety characteristics. Every phrase contributes value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only health check with one optional boolean parameter and no output schema, the description adequately covers the purpose, the safety profile, and the optional parameter. It does not describe the exact return structure, but it lists the readiness aspects, which is sufficient for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines a boolean 'run_replay_samples' with no description. The tool description references 'optional SELFTEST replay health', which gives meaning to this parameter, indicating it controls whether replay samples are used to assess health. This is a meaningful addition beyond the bare schema, though it could be more explicit about the default and exact behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Return' and clearly identifies the resource as 'ATHENA.STARTUP.1 local readiness', listing concrete aspects (mature surface, composition, schema currency, optional SELFTEST replay health). This distinguishes it from sibling tools, which focus on other domains like causal discovery, transport, or topology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating that reads remain allowed while degraded and that it does not silently change mutation semantics, indicating this is a safe read-only tool. However, it does not explicitly mention alternatives or situations when one should not use this tool, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It goes beyond typical promise semantics by clarifying that PASS validates only the evidence, not the actual system state, and enumerates non-effects (no fencing, no stopping writers, no snapshot verification, no production contact). This is exceptional transparency for a quiescence assessment tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence defines the core function, the second sentence crisply delivers critical limitations. Every clause carries meaning, and the negative list is each a separate important exclusion, not filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (4 required params, nested objects, no output schema), and the description covers purpose, scope, constraints, and side-effect exclusions. It lacks details on return value format and exact matching behavior, but the description is sufficient for an agent to decide whether to invoke it and likely accept the validated PASS semantics. The absence of output schema and annotations increases needed context, but the description still covers the essential operational envelope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description introduces meaningful semantic framing: 'exact current-image and state-snapshot coordinates' maps conceptually to the expected_current_image_ref and expected_state_snapshot_ref parameters, and 'single-writer quiescence observation' contextualizes the observation object. However, it does not explain the digest parameter's role or specific constraints beyond what the schema states (minLength 64).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Evaluate') with a precisely scoped resource ('a supplied single-writer quiescence observation against exact current-image and state-snapshot coordinates'). It also explicitly names the result semantics ('PASS validates supplied evidence only') and lists what the tool does NOT do, which distinguishes it from sibling deployment assessment tools like 'athena_deployment_assess_canary' or 'athena_deployment_validate'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what validation PASS covers ('supplied evidence only') and explicitly lists exclusions: 'it does not stop a writer, install a fence, verify a snapshot, or contact production.' This gives an agent clear when-to-use/when-not-to-use guidance and helps rule it out for operations that need actual enforcement or production contact.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![athena-mcp-server MCP server](https://glama.ai/mcp/servers/demeet2k/athena-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/demeet2k/athena-mcp-server)

Score Badge

Copy to your README.md:

[![athena-mcp-server MCP server](https://glama.ai/mcp/servers/demeet2k/athena-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/demeet2k/athena-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/demeet2k/athena-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server