Server Quality Checklist

Tool Scores

• mystorax_job_statusC
  2.4/5.0
  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. The term 'Poll' implies repeated invocation but the description doesn't clarify whether this is a blocking call, how long to wait between polls, what states the job can be in, or what happens when a job is not found. This is notable for a polling tool that agents may need to call repeatedly.

  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 brief at one line, which is efficient and front-loaded. There is no wasted language. However, the brevity borders on under-specification rather than concise completeness, though no filler exists.

  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 polling tool with no annotations, no output schema, and zero schema description coverage, the description is substantially under-equipped. It doesn't explain return format, job states, polling cadence, or error handling. The 'wait_id' reference hints at a secondary mechanism that is entirely unexplained.

  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 documenting the lone parameter, job_id. However, the description only mentions 'by job_id / wait_id' without clarifying what job_id vs wait_id are, their format, or their relationship. The description names the parameter but adds no semantic depth beyond the schema.

  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 verb+resource ('Poll durable job status by job_id') which communicates the core action. However, it doesn't differentiate from siblings like mystorax_science_status or mystorax_wait_stream_hint, which could overlap in purpose. The intent is understandable but the differentiation from other status-related 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?

  There is no indication of when to use this tool versus alternatives. The description provides no context about polling semantics (e.g., whether to poll repeatedly, expected latency, or when to prefer wait_stream_hint or submit_goal workflows). No exclusions or alternatives are mentioned.

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

• mystorax_wait_stream_hintC
  2.4/5.0
  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 does not state side effects (if any), whether it is read-only or mutating, what it produces (a string recipe? an SSE endpoint?), or its limitations. The 'recipe' language hints at returning instructional text, but there is no confirmation of return format or 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 a single short sentence with no wasted words. However, it is under-specified rather than concisely complete - brevity is achieved at the cost of missing critical operational 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?

  For a one-parameter, no-output-schema tool with no annotations, the description should fully carry the burden. It fails to explain the wait_id parameter, what the returned 'recipe' looks like, how it integrates with SSE, or the relationship to CLI token conservation. A simple wait/stream tool should be more thoroughly documented given zero supporting structured metadata.

  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 a single undocumented parameter (wait_id), the description must compensate but does not. It never mentions wait_id, what it represents (a wait identifier, session token?), or why it is optional (required params = 0). The description adds no meaning beyond the schema's bare 'string' type.

  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 references an 'SSE wait-wake recipe' and connects it to 'CLI tokens', but does not clearly state what the tool actually does, returns, or modifies. The purpose is partially discernible (provide a recipe for waiting via SSE), but vague terms like 'recipe' and 'burn tokens' obscure the exact operation. It does give some resource orientation (SSE wait-wake) but lacks a clear verb+object statement like 'Build/return a wait condition'.

  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 siblings. The phrase 'so Hands do not burn CLI tokens waiting' implies a use case (avoiding polling/token waste) but does not clarify situations where the tool should NOT be used or name direct alternatives. Sibling tools exist (mystorax_job_status, mystorax_science_status) that could involve waiting, but the description offers no differentiation.

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

• mystorax_axiom_tool_callC
  2.6/5.0
  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 burden. It does disclose the fail-closed token requirement (a genuinely useful security behavior), but doesn't describe side effects, whether calls are read-only or mutating, rate limits, or error behavior when not allowlisted. Sparse behavioral context for a proxy/invocation 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 conveys purpose and a critical security invariant (fail-closed without token) efficiently. No wasted words, though the sentence is packed and slightly opaque on first read.

  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 proxying tool with 3 parameters including nested arguments object, 0% schema coverage, no output schema, no annotations, and several sibling tools to disambiguate against. The single-sentence description is insufficient to guide correct invocation; it needs parameter semantics, usage disambiguation from siblings, and expected return/behavior context.

  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, but it only partially does. The description implies 'tool' names the Axiom tool and 'arguments' are its params, but provides no detail on the 'tool' naming format, what 'arguments' expects, or the meaning of timeout_s (units, defaults, behavior on timeout). Since 0 params are described, the description carries responsibility it doesn't fully meet.

  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 it 'Call[s] one allowlisted Axiom tool via Conductor' which gives a clear verb+resource. However, it doesn't distinguish from sibling mystorax_axiom_tool_search, and the 'Axiom tool' concept is left unexplained, so an agent can't tell what 'allowlisted' means or what this actually accomplishes versus the search sibling.

  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 provided on when to use this tool versus alternatives like mystorax_axiom_tool_search or the routing guide. The description mentions fail-closed behavior but doesn't tell the agent how to choose between this and sibling tools, nor what prerequisites or context are needed before invoking.

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

• mystorax_capability_lookupC
  2.6/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden of behavioral disclosure. It does not disclose what is returned (a list? a single match? error behavior for no matches?), whether matches are case-sensitive, whether partial matches are supported beyond the vague 'substring', or any operational constraints. The word 'Lookup' suggests read-only 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.

  Conciseness4/5

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

  The description is a single efficient sentence that wastes no words. It is front-loaded with the verb and resource. However, given the minimal content, it may border on under-specification rather than concise completeness.

  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 search/lookup tool with no output schema, no annotations, and only one parameter, the description should clarify what the result set looks like and how matches are determined. The description is too thin to be complete for an agent deciding whether this satisfies a user's lookup request, especially with several sibling tools that could overlap.

  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 100% with the only parameter 'query' documented as 'id substring or keyword'. The description restates the same semantic ('by id substring or keyword') rather than adding new meaning, but given full schema coverage, baseline 3 is appropriate. No additional value added beyond the schema.

  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 uses a specific verb ('Lookup') and identifies the resource ('surfaces/capabilities') by id substring or keyword. It distinguishes from siblings like mystorax_surfaces (which likely lists surfaces) and mystorax_axiom_tool_search, but the 'surfaces/capabilities' phrasing is somewhat ambiguous about whether it searches both or whether they are interchangeable.

  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 siblings such as mystorax_surfaces (likely a full list), mystorax_axiom_tool_search, or mystorax_capability_lookup's own search semantics. There is no guidance about when a full list vs a substring lookup is appropriate, nor any exclusions or alternative recommendations.

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

• mystorax_science_resumeC
  2.9/5.0
  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 burden of behavioral disclosure. It does disclose key behaviors: max_phases budget, auto-stop at EVIDENCE, and never auto-CERTIFY. These are genuinely useful behavioral constraints not in the schema. However, it doesn't disclose what resuming actually does to the campaign, any side effects, 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.

  Conciseness4/5

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

  The description is a single compact sentence with parenthetical constraints. It's front-loaded with the verb and resource. Every phrase earns its place by encoding key behavioral rules. It's under-specified in places, but for what's there, it's 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 moderately complex tool (7 params, 2 required) with no output schema, no annotations, and 0% schema description coverage. The description is too thin: it doesn't explain what campaign_id and goal represent semantically, what phase/effort control, what resuming entails, or what the return value looks like. The parenthetical behavior hints are good but insufficient 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 there are 7 parameters, so the description carries heavy burden. The description references 'max_phases' and 'EVIDENCE' (the default for max_auto_phase) but does NOT explain the meaning of goal, campaign_id, via, phase, or effort. The behavioral constraints mention max_phases budget but not how phase/effort relate to resumption. For a 7-param tool at 0% coverage, the description should explain more.

  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 ('Resume') and resource ('a Science OS campaign'), with some behavioral constraints in parentheses. However, it doesn't clearly distinguish this from siblings like mystorax_submit_goal (which likely is the initial action vs resuming one) or mystorax_science_status (monitoring). The purpose is clear but sibling differentiation is weak.

  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 resuming existing campaigns (as opposed to submitting new ones), but it doesn't explicitly name alternatives or state when NOT to use it. It alludes to the 'max_phases budget' and auto-stop behavior, which gives context, but there's no explicit exclusion or cross-reference to a sibling tool.

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

• mystorax_submit_goalC
  2.9/5.0
  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 an HTTP endpoint (POST /v1/goal) which implies a network operation, and lists job_class values. However, it doesn't disclose side effects, asynchronous behavior (e.g., does it return immediately and the job runs in background?), auth requirements, rate limits, or what happens on submission. The sibling mystorax_job_status and mystorax_wait_stream_hint suggest this is asynchronous, but the description doesn't confirm that.

  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, front-loaded with the core purpose and the channel preference. No wasted words. Could arguably be more efficient but it's appropriately brief.

  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?

  Has no output schema, no annotations, and 0% parameter coverage. With 8 parameters and only 1 documented, the description falls well short. It does list the job_class enum, which helps slightly, but the tool is incomplete for a 8-param submit tool with async hints from siblings.

  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 description must compensate. It only documents job_class with its enum values. The other 7 parameters (host, mode, text, model, effort, worker, dispatch) are not explained at all. text is the required parameter yet the description never even names it explicitly.

  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+resource+channel: 'Submit a goal to Conductor POST /v1/goal'. It distinguishes from siblings by saying 'Prefer this over talking to bridges or CLIs directly', which separates it from other mystorax tools. It's clear and specific but doesn't fully differentiate against all 9 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?

  It provides a clear 'prefer this over' guidance directing usage toward this tool rather than bridges/CLIs, but doesn't state when NOT to use it or what alternatives (e.g., capability_lookup, routing_guide) might be appropriate. The job_class enum values are listed, giving some usage context, but no exclusions for when other mystorax tools would be better.

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

• mystorax_surfacesC
  2.9/5.0
  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 for behavioral disclosure. It reveals the status taxonomy and optional filter but doesn't state whether this is a read-only operation, whether results are cached/ordered, what happens if an invalid ('wired' vs non-enum) status value is passed, or whether pagination/limits apply. For a listing tool with zero annotation coverage, this is a notable 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 tight single sentence of ~20 words with the key status values front-loaded and the optional filter mentioned. No wasted words. Could arguably include sibling differentiation, but strictly for length and clarity it is 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?

  For a simple 1-parameter, 0-required list tool with full schema coverage and no output schema, the description is mostly adequate. However, since there is no output schema, it should at least hint at what the response contains (e.g., surface names, IDs, properties). It also doesn't clarify the relationship to mystorax_capability_lookup. These are minor gaps for a listing tool of moderate complexity.

  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 100% (the single 'status' parameter is fully described in the schema). The description restates the filter option but adds no syntax, format, or behavior detail beyond what the schema already documents. Per the rubric, baseline 3 is appropriate when schema does the heavy lifting, and the description adds marginal value.

  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') with a clear resource ('MystoraX capability surfaces') and includes the status values ('wired|guided|inventory|refused|deferred'). It clearly distinguishes from siblings like mystorax_submit_goal or mystorax_job_status, which are action/status tools, while this is a listing tool. However, it does not explicitly contrast with the closest sibling mystorax_capability_lookup or surface its unique scope beyond listing.

  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 the filter capability ('Optional status filter') but provides no guidance on when to use this vs alternatives like mystorax_capability_lookup or mystorax_routing_guide. There is no when/when-not context or mention of what a caller should do before invoking (e.g., whether a routing guide must be consulted first).

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

• mystorax_science_statusB
  3.2/5.0
  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 indicates this is a read-oriented status operation and mentions 'readiness' and 'proxy status', but gives no detail on what readiness means, what the status output covers, or any side effects. It adds modest context but is thin for an unannotated 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 concise clause, well under a sentence, with zero wasted words. It's appropriately sized for a status tool, though TLA-heavy language (OS, Axiom, MCP) slightly hurts readability for agents unfamiliar with the domain.

  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, no-output-schema status tool, the description is serviceable but could be richer. It doesn't explain what the response contains (readiness flags, proxy health, versions) or how it relates to the mystorax_axiom_* and mystorax_science_* siblings, which limits agent confidence in using it.

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

  Parameters5/5

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

  The tool has 0 parameters and 100% schema coverage by default (no parameters to describe). The absence of parameters means the description adds no needed parameter detail; this is the correct baseline for a zero-parameter tool.

  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 'Science OS / Axiom readiness + MCP proxy status' conveys a clear status-check purpose with a verb+resource shape. However, it doesn't explicitly say it reports/displays status, and it gives no differentiation from siblings like mystorax_job_status or mystorax_science_resume.

  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 when-to-use guidance, no exclusions, and no mention of alternatives. Given six sibling tools, the description offers no roadmap for when to choose this status tool over mystorax_job_status or mystorax_axiom_tool_search.

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

• mystorax_axiom_tool_searchA
  3.6/5.0
  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 notes it does NOT dump the full catalog (a useful negative constraint) and labels itself a 'meta-proxy.' However, it doesn't describe what it returns (list of tool names? descriptions?), pagination, or how it behaves when the query matches nothing. The description adds some value but leaves behavior 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?

  Two short sentences, no filler. The second sentence adds a useful negative clarification. Concise and front-loaded, though slightly terse given that it's a meta-proxy tool worth a bit more explanation.

  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 single-param search tool with no output schema, the description is arguably adequate but thin. It doesn't describe result format, what 'search' returns (matching tool IDs? full metadata?), or sample usage. Given it's a meta-proxy whose results feed into later calls, more return-shape guidance would help. Adequate but with 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 coverage is 100%, so the single 'query' parameter is already documented as a 'substring match on tool name.' The description adds no additional parameter meaning beyond confirming the search scope ('allowlisted Axiom tools'). Baseline 3 is appropriate since the schema fully covers the one 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 states it 'search[es] allowlisted Axiom MCP tools' and clarifies it's a 'meta-proxy,' distinguishing it from actual Axiom tools. The purpose is clear, and 'meta-proxy' plus 'allowlisted' differentiates it from siblings like mystorax_capability_lookup and mystorax_axiom_tool_call. However, it doesn't explicitly state what the tool is NOT for (e.g., not calling tools directly), though the 'meta-proxy' label hints at this.

  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 discovering/searching among Axiom tools without dumping the full catalog, which gives context for when to use it. It doesn't explicitly contrast against sibling tools or state when NOT to use it, but the 'does not dump the full bio catalog' clause hints at a scoping alternative. This is reasonable but could name alternatives explicitly.

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

• mystorax_routing_guideA
  3.6/5.0
  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 describes the tool as a pure fetch/read operation on doctrine, which is behaviorally transparent about it being informational. It doesn't detail response format, caching, or side effects, but the operation is simple enough that this is acceptable.

  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, both earning their place. The first states the tool's function with content enumeration; the second gives actionable usage guidance. It's front-loaded and efficient. Minor deduction for not describing return shape, but for a parameterless fetch tool this is proportionate.

  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?

  Despite no annotations and no output schema, the description adequately covers what the tool does and when to call it. The tool appears to be a reference/doctrine retrieval mechanism with no parameters, so complexity is low. The description is complete enough for an agent to select and invoke it correctly, though it doesn't detail what the returned doctrine looks like.

  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 parameter semantics baseline is 4. The description and schema are fully aligned with no parameters to document. The content enumeration ('authors, Hands, Science OS, refusals') gives the agent a preview of what the returned doctrine covers, which is helpful context for a parameterless 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 states a specific verb+resource: 'Fetch MystoraX routing doctrine (authors, Hands, Science OS, refusals).' It names concrete content areas. It doesn't explicitly distinguish from siblings, but the enumerated content types give reasonable 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 line 'Call this before inventing routes' provides explicit usage timing guidance, telling the agent this must precede route invention. However, it doesn't contrast with alternatives or state when not to use it. The instruction is clear but not exclusionary toward siblings.

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