Server Quality Checklist

Tool Scores

• exergynet_verify_programC
  2.3/5.0
  Behavior1/5

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

  No annotations are provided, and the description fails to disclose behavioral traits such as whether the tool queries a blockchain, if it is read-only, or any side effects. The term 'check' is vague.

  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 lacks structured information. It is too brief to be fully 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?

  The tool has no output schema and the description does not explain the return value, what 'live' means, or how to interpret results. The description is inadequate 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?

  The description mentions 'Mainnet' but does not explain the purpose of the 'rpcUrl' parameter. With 0% schema description coverage, the description should compensate but fails to provide meaningful 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 states the action (check) and the specific resource (LNES-01 on Mainnet), distinguishing it from sibling tools which have different purposes (estimate_gate, get_program_id, get_proof_transaction).

  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, or any context about prerequisites or limitations. The description only states what it does without usage context.

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

• exergynet_estimate_gateC
  2.4/5.0
  Behavior2/5

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

  No annotations are present, so the description must fully disclose behavior. It states only that a calculation occurs, but does not mention side effects, authorization needs, rate limits, or whether the tool is read-only. The single sentence provides minimal 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.

  Conciseness3/5

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

  The description is extremely concise (one sentence), but this brevity comes at the cost of useful detail. While it front-loads the purpose, it omits critical information about parameters and output, making it minimally adequate.

  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 input parameters, no output schema, and no annotations, the description should provide more context about what the inputs represent and what the tool returns. The current description does not enable an agent to use the tool effectively without additional domain knowledge.

  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%, meaning parameter names and types provide the only semantic clues. The description does not explain the meaning or role of 'externalComputeCostUsd', 'settlementCostUsd', or 'riskMarginUsd', leaving the agent to infer their purpose from names alone, which is 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 clearly states the action ('Calculate') and the subject ('exergy-gate profitability'), distinguishing it from sibling tools which retrieve or verify data. However, the domain term 'exergy-gate' is not explained, which may confuse agents unfamiliar with the context.

  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 exergynet_get_program_id or exergynet_verify_program. There is no mention of prerequisites, contexts, or exclusions.

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

• exergynet_get_proof_transactionA
  3.5/5.0
  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 only states the return value without indicating side effects, mutability, or authorization requirements. The read-only nature is implied but 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 single sentence is front-loaded with the key action and resource, contains no unnecessary words, and is optimally concise 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?

  Given no parameters and no output schema, the description is adequate but minimal. It lacks context about the SettleExergy transaction and how this proof signature fits into the broader workflow, leaving some ambiguity for the 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?

  There are no parameters, and schema coverage is 100% (trivially). The description correctly avoids adding param info, meeting the baseline for zero-parameter tools.

  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 (return) and resource (proven SettleExergy transaction signature), and implicitly distinguishes from siblings which handle estimation, program ID retrieval, and verification.

  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. siblings like exergynet_verify_program or exergynet_estimate_gate. The description lacks contextual information about prerequisites or typical use cases.

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

• exergynet_get_program_idA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, and the description only says 'Return the Mainnet LNES-01 program ID'. It does not disclose behavioral traits such as whether it requires authentication, has side effects, or returns format specifics. For a read operation, more transparency would be beneficial.

  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?

  Description is a single, front-loaded sentence. It is concise, though it could further clarify that no inputs are required.

  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 zero parameters, no output schema, and a simple purpose, the description is mostly complete. It clearly states what is returned. However, it does not specify the data type of the program ID (e.g., string, number).

  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?

  Input schema has zero parameters with 100% coverage. Description adds nothing about parameters because none exist. Baseline of 4 is appropriate as it correctly indicates no arguments needed.

  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 clearly states 'Return the Mainnet LNES-01 program ID', using a specific verb and resource. It distinguishes from siblings like exergynet_estimate_gate, exergynet_get_proof_transaction, and exergynet_verify_program, which handle different operations.

  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?

  Description does not explicitly state when or when not to use this tool. It implies usage when the program ID is needed, but lacks explicit context or alternative guidance.

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