Server Quality Checklist

Tool Scores

• tokonomix_get_balanceA
  4/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 transparency burden. It does mention the authenticated key, implying authentication is needed, and the verb 'Get' implies a read-only operation. However, it does not disclose rate limits, response format, or any potential errors or side effects, 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?

  The description is a single concise sentence of 12 words that front-loads the action and resource. Every word adds value; 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 trivial read-only getter with no parameters and no output schema, the description is sufficient: it states exactly what the tool retrieves. It does not specify the response structure, but the tool's simplicity and the explicit mention of balance and tier make it likely the agent can invoke it correctly. A fully complete description might mention when the balance is unavailable (e.g., unauthenticated), but that's minor.

  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 no parameters, so the schema fully covers parameter semantics. The description adds no parameter details, but none are needed. Baseline for 0 params is 4.

  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 ('Get') and resource ('credit balance and account tier'), and it is distinct from all sibling tools which handle queries, models, skills, and onboarding.

  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 by the purpose—use when you need the current balance or tier—but there is no explicit guidance about when to prefer this over alternatives or any exclusions. The description does not reference sibling 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.

• tokonomix_list_modelsA
  4.1/5.0
  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 discloses conditional behavior (speed features not yet live, no-op filters), the advisory nature of speed data, and the meaning of 'eu' matching both eu and fr. It does not mention auth, rate limits, or errors, but for a read-only list tool 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?

  The description is moderately long but information-dense, front-loading the core action and return fields. Conditional speed behavior is explained clearly, and every sentence contributes meaningful detail. It could be slightly more concise, but it remains well-structured for the tool's complexity.

  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 8 parameters and no output schema, the description covers return values well, lists the key fields, and explains conditional speed behavior. It lacks explicit error/edge-case handling, but for a listing tool this is a minor gap. The description is sufficiently complete for an agent to use the tool 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 input schema provides 100% coverage with detailed descriptions for all 8 parameters, so the description does not need to add much. It does offer use-case framing (e.g., EU data-residency routing, speed selection) but not syntax-level additions beyond the schema. Baseline 3 is appropriate.

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

  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: 'List the active models reachable through this account.' It also enumerates the returned fields, making its purpose unambiguous. It stands apart from sibling tools, which handle balances, consensus, and skills rather than model listing.

  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 concrete usage contexts, such as filtering by EU data-residency routing and self-selecting faster models via speed filters. It does not explicitly discuss when NOT to use the tool or name alternatives, but since no sibling tool lists models, the guidance is sufficient. The no-op warning for speed filters adds important context.

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

• tokonomix_single_askA
  4.4/5.0
  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 the passthrough nature, billing model, and the trade-off with consensus. It does not mention authentication or rate limits, but for a simple call tool these are less critical. The description adds value beyond structured fields.

  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 concise (two sentences plus a tip) and front-loaded with the core purpose. Every sentence contributes to understanding the tool's role, usage, and trade-offs without 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 covers purpose, usage context, and return type. It does not detail error scenarios or authentication, but these are not typically required for a simple single-model call. The lack of an output schema is partially offset by the explicit mention of the plain answer return. Overall, complete enough for effective selection and 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 100%, so parameters are already well-documented. The description focuses on tool usage rather than parameter details, which is acceptable since the schema handles that. No additional parameter semantics beyond what the schema 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 identifies the tool as a 'Single-model passthrough call', which is a specific verb+resource. It distinguishes itself from the sibling consensus tool by mentioning cost and use cases, and it states the return value (plain answer with markup billing).

  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?

  Explicit guidance is given: 'Cheaper than consensus — use for routine reasoning, tool-orchestration, classification.' It also names the alternative tool directly: 'use `tokonomix_consensus_ask` instead when correctness matters.' This fully addresses when and when not to use the tool.

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

• tokonomix_onboard_verifyA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description fully bears the burden and excels: it discloses side effects (provisions account, writes credentials file, shows key once), the lack of API key requirement, and the postcondition that other tools become usable. This is rich, honest behavioral 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?

  Three sentences, each dense and purposeful: purpose, prerequisite, side effects. It is front-loaded with what the tool does, then explains implications. No fluff or repetition.

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

  Completeness5/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 essential behavior: input (OTP), side effects, return value (starting credit balance), and the broader onboarding context. It is complete enough 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.

  Parameters3/5

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

  Schema coverage is 100% (both parameters fully described). The description adds minor context by specifying that email must match tokonomix_onboard and code comes from the OTP email, but these are already implied in the schema. Baseline 3 is appropriate.

  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 ('Verifies the 6-digit OTP') and clearly identifies the resource ('from tokonomix_onboard'). It explicitly labels itself as 'Step 2 of keyless first-run onboarding', distinguishing it from its sibling tokonomix_onboard and other 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: it is step 2 of onboarding, must follow tokonomix_onboard, and is a prerequisite for using other tokonomix_* tools. It does not explicitly list when-not-to-use or alternatives, but the orchestration is clear.

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

• tokonomix_onboardA
  4.6/5.0
  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. It discloses that no API key is required, the server returns a 400 if beta terms are not accepted, the response is enumeration-safe, and success returns {ok:true} regardless of existing accounts. It also explains the beta terms URL and the importance of human confirmation.

  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 somewhat long but every sentence contributes value—it covers the purpose, beta terms caveat, fallback behavior, and next step. It is front-loaded with the main action and flows logically. A slight trim could be made, but it remains efficient for the information density.

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

  Completeness5/5

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

  Given the onboarding flow complexity (OTP, beta terms, enumeration safety) and the absence of an output schema, the description provides sufficient context for an agent to invoke correctly. It explains the conditional 400 response, the meaning of accept_beta_terms, and the follow-up verify step, making it complete for this tool's role.

  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 100%, so the baseline is 3. The description adds behavioral context beyond the schema, particularly for accept_beta_terms, explaining when to set it true and the consequence of not doing so. It also clarifies the email's purpose and the optionality of name and locale, which is meaningfully more than 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 opens with 'Step 1 of keyless first-run onboarding' and clearly states it 'Sends a 6-digit OTP to the provided email address.' This gives a specific verb, resource, and step designation. It also distinguishes itself from the sibling tool tokonomix_onboard_verify by explicitly directing the user to call that tool after a code is sent.

  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 is the entry point for new users, no API key is required, and the beta terms acceptance flow is explained with a fallback. It explicitly instructs the agent to confirm beta terms with the human and then call with accept_beta_terms: true, and to direct the user to the verify step. However, it does not explicitly state when NOT to use this tool or mention alternative sibling tools beyond the next step.

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

• tokonomix_rate_consensusA
  4.6/5.0
  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. It covers idempotency patterns (per-account dedup, last-write-wins), authentication requirements, feature-gating with a non-error response, storage/privacy guarantees (admin-only, never returned, EU-hosted enrichment), and the relationship between auto-scoring and user-supplied bucket counts. This is exemplary 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 front-loaded with the core purpose and logically progresses through optional parameters before behavior. It is nevertheless lengthy and includes some non-essential details (e.g., 'INT-1882', 'red-thread blind-spot differentiator', 'Opt-in, no friction') that could be trimmed without losing practical guidance. Dense but slightly overpacked.

  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 tool with 7 parameters, nested objects, and no output schema, the description covers input semantics, privacy, dedup, auth, feature-gating, and even the discount incentive. However, it does not describe the successful return value or acknowledgment after a rating is submitted; this is a minor gap given the tool's rating confirmation purpose. Overall, it is nearly complete for the agent's decision-making.

  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?

  Schema coverage is 100%, so baseline is 3, but the description adds substantial meaning beyond field names. It explains how to obtain request_id ('billing breakdown line' and 'x_council.request_id' metadata), clarifies helped_model's blind-spot credit semantics, details that findings are counts only and must not exceed produced bucket counts, and positions consensus_benefit as a privacy-safe replacement for free text. This is far more than schema labels provide.

  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 action: 'Rate a consensus call 1–10 on real-world usefulness, after you have seen the answer play out.' It clearly identifies the resource (consensus call), references the originating tool (tokonomix_consensus_ask), and distinguishes itself from sibling tools by focusing on post-hoc rating rather than asking or listing.

  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 when to use the tool ('after you have seen the answer play out'), imposes a precondition ('Requires the same API key that made the original call'), and mentions the feature-gated behavior with a clear 'not enabled' message. It does not explicitly name alternatives like tokonomix_relay_human_feedback, but it does contrast agent-source feedback from human-feedback summaries, implying a specific niche.

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

• tokonomix_consensus_askA
  4.7/5.0
  Behavior5/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 exceeds it. It discloses the judge is 'disjoint from the proposers, never scoring its own answer,' does NOT guarantee correctness because 'frontier models share training data,' and details cost ('a few cents'), latency, per-proposer 60s timeouts, and judge output hard-cap. It even flags response-state behaviors like 'needs_context' and 'grounding:insufficient.'

  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 long but front-loaded: purpose, usage, then modes. Every section earns its place given the tool's 12 parameters and absence of annotations, but it is slightly sprawling, with a few cautionary themes (grounding, correctness) restated across sections rather than consolidated.

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

  Completeness5/5

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

  The description is unusually complete for a tool with no output schema and no annotations. It covers purpose, safety limits, cost, latency tradeoffs, mode-specific behaviors, grounding/continuation flows, model selection, and failure/edge cases (skipped models, 400 on single non-vision model, judge truncation).

  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?

  Although schema coverage is 100%, the description adds substantial meaning beyond the bare schema. It maps each mode to an intent (e.g., 'diff' = judge compares but does not decide), warns that max_tokens past 8192 can truncate the judge, explains that an explicit single non-vision model returns 400, and clarifies request_id continuation semantics versus a fresh chargeable request.

  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: 'Ask 2-6 frontier LLM proposers (parallel + blind) and reconcile via an independent judge,' which clearly states what the tool does. It also distinguishes itself from siblings by framing it as 'a recall amplifier that surfaces disagreement a single model hides,' implicitly contrasting with tokonomix_single_ask.

  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?

  Explicit when-to-use guidance is present: 'Use this when correctness matters more than latency' and 'Proactively offer it... before anything irreversible or with real consequence.' It also gives when-not-to-use: 'skip routine or reversible work.' However, it does not explicitly name an alternative tool (e.g., tokonomix_single_ask) for the lighter cases, only implying a single-model alternative.

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

• tokonomix_get_skillA
  4.7/5.0
  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 version-specific behavior and caching implications ('for this MCP-server version', 'newer than your cache'). While it does not explicitly state that the operation is read-only or describe the exact output format, the context supplied is useful and goes 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: the first states the core function, the second provides usage guidance and a brief overview of the skill content. Every sentence earns its place, and it is front-loaded with the primary purpose.

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

  Completeness5/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 annotations and no output schema, the description covers the purpose, when to use it, and what the returned skill explains (modes, consensus vs passthrough). It is complete for the tool's 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?

  With zero parameters, the baseline is 4 per the rubric. The description adds relevant context about version-specific content and cache usage, which is not represented in the schema. There are no parameters to explain, so this is appropriate.

  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 'canonical Tokonomix consensus SKILL.md content for this MCP-server version', which is a specific verb+resource that distinguishes it from siblings like tokonomix_consensus_ask or tokonomix_single_ask. It is unambiguous and not a tautology.

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

  Usage Guidelines5/5

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

  Explicit guidance is given: 'Use this on first connection, or when tokonomix_skill_version reports a version newer than your cache.' This directly tells when to invoke the tool and references a sibling for version checking, providing clear usage context.

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

• tokonomix_skill_versionA
  4.7/5.0
  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 behavioral disclosure. It states 'No network call' (indicating a cheap, local operation) and lists the exact return fields ({version, sha256, last_changed, bytes}), providing useful context. It does not explicitly state there are no side effects, but the nature of a fingerprint check implies a safe read-only operation. The absence of any warning about permissions or failure modes is acceptable for this simple 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 core purpose, and includes just enough detail (return fields and usage trigger) without redundancy. Every sentence adds value, making it both concise and well-structured.

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

  Completeness5/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, the description provides a complete picture: what it returns (the hash and metadata), why it exists (detect stale cache), and how to act on the result (call tokonomix_get_skill). The tie-in to sibling tools ensures the agent understands where this fits in the broader workflow.

  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 takes zero parameters, so there is nothing for the description to clarify about inputs. Baseline for 0 params is 4, which is appropriate since the description does not need to compensate for any undocumented 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 returns a 'cheap version fingerprint' of the canonical SKILL.md, specifying the verb ('Return'), the resource ('version fingerprint of the canonical Tokonomix SKILL.md'), and its role in detecting stale caches. It distinguishes itself from siblings by explicitly framing itself as the lightweight version check, with tokonomix_get_skill as the refresh mechanism.

  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?

  It provides explicit when-to-use guidance: 'Use this to detect that your local cached SKILL.md is stale' and includes a conditional action: 'if your cached version differs from the returned one, call tokonomix_get_skill to refresh.' This names the alternative tool and gives a clear decision procedure.

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

• tokonomix_relay_human_feedbackA
  4.8/5.0
  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. It discloses privacy handling ('stored admin-only, never returned verbatim'), the difference in reward rate versus agent-source rate, and the fallback behavior when disabled ('returns a clear "not enabled" message instead of an error'). It also explains where request_id comes from, adding meaningful 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 long but efficiently packed; every sentence earns its place. It is front-loaded with the core purpose, then proceeds through usage constraints, parameter sources, legend, privacy, reward, and error behavior. Dense but structured, with separators that aid scanning.

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

  Completeness5/5

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

  For a three-parameter tool with no output schema, the description is remarkably complete. It covers when to use (human feedback relay), how to get request_id, what each choice means, optional free_text constraints, privacy, reward implications, and disabled-platform handling. No important aspect appears missing.

  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 100%, so baseline is 3. The description adds value beyond the schema: it tells the caller exactly how to obtain request_id (from the billing breakdown line and x_council.request_id metadata), explains the choice legend in a human-mapping context, and provides extra detail about free_text trimming and privacy. This exceeds baseline.

  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: 'Relay the HUMAN end-user's verdict on a consensus call.' It explicitly distinguishes itself from sibling tokonomix_rate_consensus (the AGENT's own rating), and the verb 'Relay' with the resource 'human end-user's verdict' is 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 Guidelines5/5

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

  Usage conditions are explicit: 'Use this ONLY when a real human in the session actually told you what they thought' and 'NEVER fabricate or guess... if no human weighed in, do not call this tool.' It also contrasts with tokonomix_rate_consensus to clarify when each applies, providing clear decision guidance.

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

• tokonomix_uploadA
  4.9/5.0
  Behavior5/5

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

  With no annotations, the description carries full responsibility. It discloses key behaviors: ephemeral storage (auto-purged), region-pinned (EU default), SSRF safety (never fetches caller URL), and feature-gating (returns 'not enabled' instead of error). This is exceptional transparency beyond basic parameter descriptions.

  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 dense but every sentence adds value: purpose, workflow, ephemeral/security properties, feature-gate, and alternative usage. It is structured with a clear logical flow and no filler.

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

  Completeness5/5

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

  This tool has a simple schema but significant behavioral complexity. The description covers return value semantics, the expected follow-up call, security constraints, and error handling. Since there is no output schema, the description adequately fills that gap.

  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 100%, with per-field descriptions. The description adds context about how files are processed (verbatim vs digested, server-bounded budget) and how the result is used, which goes beyond the schema. It does not restate parameter names, but its extra semantic layer about staging behavior earns a 4.

  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: "Stage large context (over the inline cap) for a grounded consensus call." It clearly differentiates from siblings by referencing tokonomix_consensus_ask and inline context, and it states the return type (session + handles). This is a model of purpose clarity.

  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 explicitly provides usage guidance: use this tool for large context (over the inline cap) and use inline context.inline for small payloads. It also explains the workflow (pass the returned session to tokonomix_consensus_ask) and the feature gate behavior, which helps the agent decide when to invoke this tool.

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