Server Quality Checklist

Tool Scores

• get_din5008_specB
  3.3/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 burden. It names the specific geometry elements returned, which gives the agent a reasonable idea of the output scope. However, it doesn't disclose return units nuance (assumes mm is noted in description itself), format, or whether it's language-dependent. For a read-only query 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?

  Single concise sentence that front-loads the core purpose ('Returns the millimetre geometry of the layout') and then enumerates specifics. No wasted words, appropriately sized for a parameterless query tool.

  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?

  The tool is simple (zero params, no output schema), so the description's scope is adequate. However, no output schema exists, so the description is the only source of output information. It lists the geometry components well but could note that 'mm' is the unit (it does mention millimetre), and could mention if values are required for constructing letters with create_letter. Slightly thin for a tool with no output schema.

  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?

  Tool has zero parameters with 100% schema coverage, meaning there's no schema burden to compensate for. The description meaningfully explains what the returned geometry contains, which is valuable since the agent cannot otherwise predict the output. Baseline for 0 params is 4.

  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?

  Describes a specific verb+resource (get geometry of DIN 5008 layout) and enumerates the specific geometry elements: address field, remark zone, writing margins, subject position, fold and punch marks. Clear enough to distinguish from siblings, though it doesn't explicitly differentiate from siblings like preview_letter.

  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 call this tool vs alternatives. There's no mention of use cases, prerequisites, or exclusions. While siblings like preview_letter or create_letter clearly differ, the description doesn't explicitly say when to use this instead.

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

• list_fontsA
  3.5/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 of behavioral disclosure. It mentions the dual behavior (listing built-ins AND resolving a name against system fonts), which is genuinely useful. However, it doesn't disclose the return format, behavior when family is invalid/not found, or any side effects, though as a read-only listing tool the stakes are relatively low.

  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?

  One well-formed sentence that conveys purpose and context efficiently with zero waste. It is appropriately front-loaded and compact; no redundant phrasing or filler.

  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 simple read-only listing tool with 1 optional parameter, 100% schema coverage, and no output schema, the description is reasonably complete. It covers both behaviors (listing and resolution) and ties to the create_letter use case. The main gap is not describing return values, but the tool's simplicity keeps this from being a major deficiency.

  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 schema already documents the family parameter as a font family or .ttf path. The description adds the semantic connection that resolution is against installed system fonts and relates to create_letter embedding, which adds modest value beyond the schema. A baseline 3 is appropriate when the schema carries the parameter documentation load.

  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 combined with a clear resource (font families) and adds the resolution behavior against system fonts. It distinguishes itself from siblings by tying it to create_letter embedding, though it doesn't explicitly differentiate from other listing tools like list_locales or list_profiles beyond the subject matter.

  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 usage context ('so you can check what create_letter would embed'), which gives some when-to-use guidance. However, it doesn't explicitly state when NOT to use it, mention that the family parameter is optional, or clarify alternatives among sibling tools.

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

• list_localesA
  3.5/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 burden. It describes this as a read/list operation implicitly through the verb 'Lists', and clarifies the scope of what's returned. However, it doesn't describe return format, whether the optional locale filter changes response shape, or any side effects (though for a list tool these are minimal).

  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?

  Single, information-dense sentence with zero waste. It communicates the subject (languages), the action (lists), and the returned content (fixed texts with enumerated examples).

  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 list tool with one optional parameter fully documented in the schema, the description is adequate. It names the return content (fixed texts) and the subject. It could add a note about the default behavior when no locale is given (all locales vs. all), but with the schema covering the parameter and a list tool's inherent simplicity, this is reasonably complete.

  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 schema documents the 'locale' parameter as 'Return the labels of a single locale.' The description doesn't add additional meaning about the locale parameter beyond the schema, but it does contextualize that the full output includes fixed texts, which helps infer the filter behavior. Baseline 3 is appropriate since schema carries the documentation load.

  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?

  Clear verb+resource: 'Lists the supported languages' combined with what data is returned (fixed texts like salutation, closing, enclosures, page numbering). Distinguishes from siblings like list_fonts and list_profiles by naming its subject 'locales/languages'. Doesn't explicitly differentiate from all siblings but the resource is clearly unique.

  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 when to use it (need to see supported languages and their fixed texts), but gives no explicit when-not-to-use or alternatives. It's a simple list tool among create/preview/letter tools, so the context is clear, but no exclusions are stated.

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

• create_letterA
  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 full burden of behavioral disclosure. The description does a strong job: it reveals the fixed house layout (DIN 5008 address field, 25mm margin, fold/punch marks), the intended signature overlap ('The signature image intentionally overlaps the closing line'), and the return format (file path, page count, layout metrics, warnings). This is meaningful behavioral context 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 compact (three sentences) and front-loaded with the core purpose. Every sentence earns its place: what it renders, the fixed-layout constraint, a notable quirk (signature overlap), and the return value. It is not padded with schema-echo.

  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?

  This is a complex tool (22 params, nested objects, no annotations, no output schema), yet the description covers the fixed layout constraint, the signature overlap behavior, and the return payload. The high schema coverage (86%) lets the schema carry the parameter details, and the description compensates for the format/layout context. The main gap is not naming sibling alternatives for when to choose this vs preview_letter, but the description is otherwise thorough for its 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 description coverage is high at 86%, so the schema documents most parameters well. The description itself does not enumerate individual params (correctly, given coverage), but it does add behavioral semantics around the signature image and layout. Baseline 3 applies given high schema coverage; the description adds some value beyond it.

  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+resource combination ('Renders a letter as a PDF file') with detail about the layout (DIN 5008, 25mm margin, fold/punch marks, bold subject). It clearly distinguishes from siblings like preview_letter through 'in the fixed house layout' and 'Pass content only, the layout is fixed.' This 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 Guidelines3/5

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

  The description gives a clear usage directive ('Pass content only, the layout is fixed') and notes when a profile should be used vs typing a sender (in the schema, not the description). However, the description does not explicitly state when to use this vs preview_letter, list_profiles, or get_din5008_spec, nor provide exclusion conditions. The context implies usage well but lacks explicit alternative differentiation.

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

• list_profilesA
  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 carries the full burden of behavioral disclosure. It discloses the machine-local scope, which is a meaningful behavioral trait. However, it doesn't describe the return format, count expectations, or whether profiles are user-managed, leaving the shape of results unspecified.

  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 sentences, no filler, each earns its place. The first states the action and scope; the second explains the domain meaning and downstream use. Efficient and front-loaded with the action.

  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 parameterless list tool with no output schema, the description covers the essential purpose and downstream coupling well. The only minor gap is not describing the response structure (e.g., list of profile keys/addresses/signatures), but for a zero-parameter, list-only read tool the coverage is strong.

  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, so there are no parameter semantics to document. The description focuses instead on the output concept (what a profile entails) and how the output couples to create_letter, which is the appropriate emphasis for a parameterless tool.

  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+resource combination ('Lists the sender profiles configured on this machine'), clearly distinguishing itself from siblings like list_locales and list_fonts. It also explains that each profile carries address and signature, adding domain-relevant detail beyond a generic enumeration.

  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 implicitly signals usage context (listing profiles to obtain a key for create_letter), which orients the agent on why this tool exists in the workflow. However, it does not provide explicit when-to-use vs when-not-to-use guidance or name alternatives, though the relationship to create_letter provides useful context.

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

• prepare_signatureA
  4.2/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 transparency burden. It discloses the external sharp dependency requirement, describes the transformation behavior (cropping, transparency, recolouring), and names the output file. It doesn't disclose potential destructive overwrite behavior of the output path beyond implying output, though a boolean 'overwrite' parameter is present. Slightly incomplete but reasonable disclosure for the 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?

  Three tight sentences: what the tool does, what it outputs and how it plugs into the pipeline, and the one external prerequisite (sharp). Zero filler, every sentence earns its place, and the most important information (purpose+output) is front-loaded.

  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 an 8-parameter tool with no output schema, the description explains the core workflow (scan → clean PNG → create_letter). The sharp dependency note, output path default, and pipeline integration collectively give adequate context. It could mention default behaviors of trim/removeBackground (true) more explicitly, but the schema documents those. Reasonably complete for this 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 high at 88%, with most parameters having descriptive text. The description itself adds the key linking insight that the output PNG is intended for create_letter. It doesn't elaborate on parameter interplay (e.g., path vs base64 alternatives), but the schema already documents most parameter meanings well, so the high coverage makes an above-description contribution unnecessary.

  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 verb (clean up/prepare), the resource (scanned signature), the specific operations (crops white borders, turns background transparent, recolours ink), and the output format (PNG). It also explicitly differentiates from siblings by noting the output 'can be passed to create_letter as signature.path', establishing its role in the pipeline.

  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 operational context: it processes a scanned signature and produces a PNG for use with create_letter. It mentions the sharp dependency as a prerequisite for additional formats. However, it does not explicitly state when NOT to use it or name direct alternatives among siblings (create_letter consumes the output rather than competing).

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

• preview_letterA
  4.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 carries the full burden. It discloses key behavioral traits: in-memory rendering, no file written, returns layout metrics and warnings (fits address field, second-page detection). However, it doesn't describe return format, pagination behavior details, or what specific warnings/layout metrics are returned beyond the two examples.

  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 sentences, zero waste. The first states what it does, the second states when to use it. Front-loaded and efficient.

  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 large 19-param schema with 84% coverage and nested objects, the description is reasonably complete for a preview/validation tool. No output schema exists, but the description at least signals the nature of returns (layout metrics, warnings). Could add the exact set of warnings/metrics, but the tool's purpose as a dry-run check is well covered.

  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 84%, so the schema documents most parameters adequately. The description adds modest value referencing 'address field' and 'second page' as the metrics it checks. It doesn't re-explain individual parameters, which is appropriate given high schema coverage. Does not compensate for the ~16% undocumented scope, but baseline 3-4 is warranted.

  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+resource ('Renders the letter in memory and returns layout metrics and warnings') and clearly distinguishes from siblings by stating it operates 'without writing a file.' It contrasts with create_letter among siblings, making its purpose 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?

  The description explicitly states when to use it: 'Use it to check whether the address fits the address field or the letter runs onto a second page.' This gives concrete scenarios and implies it's a validation step before create_letter, though it doesn't name the alternative tool explicitly.

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