Server Quality Checklist

Tool Scores

• voice_learnA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description must carry the full burden. It adds useful behavioral context: 'Takes a few seconds,' source-specific requirements ('needs path' for chatgpt/files), and the notion of refreshing. However, it does not explicitly clarify the default replace-vs-append behavior or potential side effects beyond what the schema already states. The phrase 'Build or refresh' is somewhat ambiguous.

  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 and efficiently front-loads the purpose: first sentence defines the action, second sentence lists sources and timing. No filler or redundancy; every clause contributes.

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

  Completeness4/5

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

  For a 4-parameter tool with no output schema, the description covers the essential context: what it does, what sources exist, prerequisites, and when to run it. It could be improved by explicitly stating the default append behavior, but overall it is complete enough for an agent to invoke correctly.

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

  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 meaningful detail to the 'source' enum by explaining each value (e.g., 'claude-history' is local Claude Code history, 'chatgpt' needs a conversations.json export, 'files' is a folder of writing). It also notes the path requirement for two sources, reinforcing 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 starts with 'Build or refresh the voiceprint from the user's own writing,' which clearly states the action (build/refresh) and the resource (voiceprint). It distinguishes itself from sibling tools like voice_get (retrieve) and voice_score (evaluate) by focusing on creation/update.

  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 explicit timing: 'Run this once at setup, or again to fold in newer writing.' It also details the source options and prerequisites. It does not explicitly name alternative tools or state when not to use it, but the context is clear enough.

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

• voice_statusA
  4.2/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 full burden of behavioral disclosure. It uses 'Check' to imply a read-only operation and describes the information returned (sample count, word count, build time, corpus stability). However, it does not state the return format, potential errors, or any prerequisites beyond the setup implication.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is only two sentences, front-loaded with the action, and every phrase adds value. It is concise, structured, and free of 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 tool is simple with no parameters and no output schema, so the description must explain what it returns. It does so by listing the data points it provides, and it gives usage context. The only gap is the lack of explicit return structure, but that is acceptable for such a simple tool.

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

  Parameters4/5

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

  The tool has zero parameters, and the schema is empty, so the description does not need to add meaning for parameters. The baseline of 4 for zero-parameter tools is appropriate, as there is nothing to describe.

  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 ('Check') and resource ('voiceprint'), and lists the exact aspects it assesses (sample count, word count, build time, corpus stability). This distinguishes it from sibling tools that get, score, verify, learn, note, or export voiceprints.

  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 an explicit use case: 'Use this when you are not sure the user has set being-human up yet.' This gives clear context for when to invoke the tool. However, it does not mention alternatives or exclusions, so it stops short of a perfect score.

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

• voice_exportA
  4.3/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 discloses output formats and a character limit for chatgpt, but does not state whether the operation is read-only, writes files, or returns a value. Side effects and permissions are unmentioned.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Two tightly written sentences. The first lists all targets compactly, and the second gives usage context. No wasted words.

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

  Completeness4/5

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

  For a one-parameter tool with no output schema, the description covers purpose, usage, and parameter semantics well. The only gap is not explicitly stating what the tool returns or whether it has side effects, which is minor given the tool's simplicity.

  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% and the schema only provides an enum. The description adds detailed semantics for each enum value (e.g., 'chatgpt' => custom instructions box, ~1500 chars; 'agents' => AGENTS.md), fully compensating for the schema's lack of explanations.

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

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('compile') and resource ('voiceprint') and clearly distinguishes the tool from siblings by listing exact output formats. It unambiguously states what the tool does.

  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 with 'Use when the user wants their voice set up in a different assistant.' It does not explicitly state when not to use or name alternatives, but the sibling tool names and the format list imply the scope.

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

• voice_getA
  4.5/5.0
  Behavior4/5

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

  There are no annotations, so the description carries the full burden. It discloses that the tool measures rules from past writing (sentence rhythm, casing, punctuation rates, vocabulary, words to avoid), that they override defaults, and that the tool is 'cheap and fast.' It does not explicitly state side-effect-free or mention error/insufficient-data behavior, but for a simple getter this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is compact yet information-dense. Each sentence serves a purpose: defining the output, providing an imperative usage cue, explaining the source and authority of the output, and emphasizing cost/benefit. There is no wasted wording or repetition beyond the intended emphasis.

  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 and no annotations, the description is remarkably complete. It tells the agent what the tool does, when to use it, why it matters, what data informs it, and what the behavioral characteristics are. The sibling context further clarifies its niche without needing extra explanation.

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

  Parameters4/5

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

  The tool has zero parameters, and the schema has 100% coverage (empty object). Per the rubric, a baseline of 4 applies when there are no parameters. The description doesn't need to explain parameter semantics.

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

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Get the user's measured writing voice as explicit rules.' It clearly distinguishes from sibling tools by focusing on retrieval of explicit rules rather than scoring, verification, status, learning, noting, or export. The scope is well-defined.

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

  Usage Guidelines4/5

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

  Provides explicit guidance on when to call: 'CALL THIS BEFORE writing any prose the user will send or publish under their own name' with concrete examples (post, email, reply, bio, etc.). It also explains why it should be used ('they override your defaults') and gives negative guidance ('call it rather than guessing'). It does not name sibling tools as alternatives, so it falls slightly short of a 5.

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

• voice_scoreA
  4.5/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 burden. It richly discloses how scoring works: curated slop lexicon, structural signals, comparison against the user's baseline, and thresholds (>85 human, <50 slop). It also notes that voice rules are returned, giving the agent a complete behavioral model.

  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 efficient and front-loaded: purpose in the first sentence, usage directive second, then methodology and thresholds. Each sentence earns its place with no fluff.

  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 tool's complexity and lack of output schema, the description covers what it does, when to use it, how it evaluates, thresholds, and that it returns voice rules. This is complete enough for an agent to invoke it correctly.

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

  Parameters3/5

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

  Both parameters (path and text) are fully described in the schema, so coverage is 100%. The description adds no additional parameter meaning beyond what the schema already provides, matching the baseline of 3.

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

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly defines the tool as scoring a draft 0-100 for AI tells and returning line-level findings. This is a specific verb+resource+output that distinguishes it from sibling voice_* 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?

  It explicitly states when to use the tool: 'CALL THIS ON EVERY DRAFT before showing it to the user.' This gives clear usage context, though it does not mention when not to use it or alternative tools.

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

• voice_verifyA
  4.7/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 the statistical method (null resampled from the user's own writing, same length), defines thresholds (under 75, over 97), and notes that it names specific words that fall outside the range—providing thorough behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Every sentence earns its place: it defines the purpose, explains interpretation, contrasts with sibling, gives usage guidance, and mentions output. The description is dense but not wordy, and it is front-loaded with the core concept.

  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?

  Despite having no output schema, the description explains the return value (authorship percentile) and the additional output (specific out-of-range words). It provides enough context for the agent to understand when to use the tool and what to expect.

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

  Parameters3/5

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

  The schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description mentions 'text' but does not elaborate on the 'path' parameter; it adds no semantic value beyond what the schema already provides.

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

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as an authorship verification test ('impostor test') and explains its output (authorship percentile). It distinguishes itself from voice_score, making the purpose unambiguous and specific.

  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 instructs to run both voice_verify and voice_score on any draft before showing it, and explains the difference in what each catches. This gives clear when-to-use and when-not-to-use guidance that differentiates from sibling tools.

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

• voice_noteA
  4.8/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the full burden. It discloses that notes persist across rebuilds and matter more than statistics, which is useful behavioral context. However, it does not mention return value or whether notes overwrite or append, which is a minor gap but acceptable for such a 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 three sentences, each with a distinct role: purpose, usage triggers, and persistence context. It is front-loaded with the core function and contains no filler 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 single-parameter tool with no output schema, the description covers the purpose, when to use it, content guidelines, and persistence behavior. It is fully self-contained and leaves no critical questions unanswered about how or why to invoke the tool.

  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?

  Despite 100% schema coverage, the description significantly enhances the parameter's meaning by providing concrete examples of what to record (banned phrases, audience, corrections, running jokes). This goes far beyond the schema's generic 'rule or observation' and helps the agent craft effective notes.

  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 explains that the tool records qualitative notes about the user's voice, with specific examples of what to record. This distinguishes it from sibling tools like voice_get, voice_score, and voice_learn, which handle measurement, analysis, or learning. The verb 'Record' and resource 'something about the user's voice' are concrete 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?

  It explicitly states when to use the tool: 'Use this whenever the user says...' with concrete trigger phrases like 'I wouldn't say that' or 'too formal'. This provides clear decision guidance, and the distinction from statistical measurement implies that this is for subjective, non-measurable feedback.

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