Server Quality Checklist

Tool Scores

• telos_verifyA
  3.8/5.0
  Behavior4/5

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

  With no annotations, the description fully covers behavioral traits: it recomputes the integrity hash, is key-free, not a signature check, and returns specific fields. This is sufficient transparency for a read-only verification, though potential errors or side effects are not mentioned.

  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 well-structured with Args and Returns sections, making it easy to parse. It is concise but contains some redundancy (e.g., 'receipt' mentioned multiple times). Overall, it earns its length without being verbose.

  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 an implied output schema, the description is quite complete, covering the return keys and the verification process. It lacks error handling info, but given the tool's simplicity, it provides sufficient context for an AI 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?

  The schema provides only a type: string for receipt_json. The description adds that it can be a JSON string or object, and describes the return dict in detail. This adds significant meaning beyond the schema, though more precise format requirements could 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 tool verifies an unsigned integrity-hash receipt offline, using a specific contract. It explains the action and distinguishes from a signature check. However, it does not explicitly differentiate from sibling tools like telos_score or telos_audit, leaving the AI to infer context.

  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 via phrases like 'offline' and 'key-free', suggesting it is for verification without keys. But it lacks explicit guidance on when to use this vs. alternatives (e.g., telos_score for scoring, telos_audit for auditing). No when-not-to or exclusion criteria are provided.

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

• telos_scoreA
  3.9/5.0
  Behavior3/5

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

  No annotations are present, so the description carries full burden. It describes the return format and the receipt miniting but does not disclose whether the tool has side effects, requires authentication, or is read-only. The behavior is partially 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 well-structured with sections, front-loads the core purpose, and provides necessary details. While slightly lengthy, it earns its space given 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 the tool has three parameters, an output schema with nested objects, and a complex return, the description covers the verdict, scores, and receipt. It could add more detail on the dimension breakdown but is sufficient for an agent to understand core behavior.

  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 adds meaningful context for all three parameters via the Args section, explaining each parameter's role. However, it does not detail types or constraints beyond 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 scores a proposed agent action against the active Purpose Anchor, returning a verdict and 6-dimension breakdown. It also mentions the minting of an integrity-hash receipt for verification by telos_verify, distinguishing it from 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 the tool is used to score actions against the purpose anchor but does not explicitly state when to use it over siblings like telos_verify or telos_audit. No when-not-to-use guidance is provided.

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

• telos_get_paA
  4/5.0
  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 implicitly indicates a read operation but does not explicitly state it is read-only, nor does it cover permissions, error handling, or edge cases like invalid agent_id.

  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 and well-structured: a one-line purpose, a helpful paragraph on what the PA is, and clearly labeled Args and Returns sections. Every sentence adds value.

  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, the description covers purpose, parameter, and return structure adequately. However, it lacks error handling or prerequisite information, making it slightly incomplete.

  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 coverage, the description includes an 'Args' section that clearly describes agent_id as 'Stable identifier of the agent whose PA to load', adding meaning over the schema's minimal title.

  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 'Return the active Purpose Anchor for an agent' with a specific verb and resource, and distinguishes from siblings like telos_score and telos_verify which perform different actions.

  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 retrieving governance settings but does not explicitly state when to use this tool over siblings or provide exclusion criteria. No alternatives are mentioned.

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

• telos_replayA
  4.2/5.0
  Behavior4/5

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

  Discloses async behavior ('Returns immediately with a job id; poll the result'), includes return keys. No annotations provided, so description carries the burden well. Could mention 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.

  Conciseness4/5

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

  Well-structured with summary and docstring sections (Args, Returns). Slightly verbose but front-loads purpose. Every sentence adds value.

  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?

  Covers input parameters, async behavior, and return format. Lacks clarification on CCRS and Mode C terminology. Output schema presumed from description.

  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 0%, but description adds detailed semantics: 'receipt_id: ID of the receipt to replay against' and 'alt_config_path: Path to the alternate config (YAML) to apply.' Adds meaning beyond property 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?

  Explicitly states 'Queue a CCRS counterfactual replay against an alternate config,' with specific verb and resource. Distinct from siblings like telos_score and telos_verify, which are about scoring and verifying.

  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 usage via description of functionality but no explicit when-to-use or alternatives. No exclusions given.

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

• telos_auditA
  4.7/5.0
  Behavior5/5

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

  No annotations present, so the description bears full responsibility. It discloses the 100-entry cap, the return structure including a 'capped' boolean, and the required ordering of parameters.

  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?

  Well-structured with summary, cap note, args, and returns sections. Concise enough but could be slightly tighter.

  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?

  With 2 parameters and an output schema (implicit from description), the description covers all necessary context: input format, cap, return shape. No gaps.

  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 0%, but the description fully explains both parameters: ISO-8601 format with examples, and the constraint that end_iso must be later than start_iso.

  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 it 'Return audit chain entries within a time window' using a specific verb and resource. The sibling tools (telos_score, telos_verify, etc.) have distinct names, so no confusion.

  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?

  Describes when to use (audit queries) and provides a when-not (deeper queries via the resource). Does not explicitly contrast with siblings but their names imply different functions.

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