Server Quality Checklist

Tool Scores

• compile_templateC
  2.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full behavioral burden. It does not disclose whether this performs a write/mutation (it produces a file), whether compilation is destructive to existing files, what the output (PDF) location or naming behavior is, or what happens on engine failure. The engine parameter (xelatex vs pdflatex) reveals compilation behavior but is not explained in the description.

  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?

  A single, efficient sentence with zero filler. It names the core inputs (template, JSON variables) and outcome (PDF). However, given the 4-parameter schema, the brevity borders on under-specification rather than disciplined conciseness.

  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 4 parameters, 0% schema description coverage, no output schema, and no annotations, this is a moderately complex tool (engine selection, variables object, output file). The one-sentence description is insufficient to cover engine semantics, variables schema, filename behavior, and error handling. The description is not 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.

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for the 4 parameters, but it barely does. It mentions that 'variables' holds JSON and 'template_name' selects a template, but gives no guidance on the 'engine' enum values (when to choose xelatex vs pdflatex), the optional 'filename' behavior (default naming? file extension?), or the shape expected within the variables object. With 0% coverage, this is a significant gap.

  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 verb ('render'), resource ('named resume template'), and outcome ('compile to PDF'). It distinguishes from siblings like export_tex (which presumably produces LaTeX, not PDF) and preview_resume. Could be clearer about the 'JSON variables' mechanism, but the core purpose is well expressed.

  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?

  The description does not explain when to use this tool versus compile_resume, which appears to be a near-sibling (compiling resumes). No exclusions or alternate-tool references are given. The agent has no guidance on choosing between compile_template and compile_resume beyond the template-focused name.

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

• export_texC
  2.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden for behavioral disclosure. It mentions writing to an output directory but doesn't state whether an existing file gets overwritten, what happens if the directory doesn't exist, whether the file is committed/persisted in the workspace, or what side effects occur. For a write operation with zero annotation coverage, this is a meaningful gap.

  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?

  A single clear, efficient sentence with zero filler. The core purpose is front-loaded. It's concise but arguably under-specifies given the 0% parameter coverage and absent annotations.

  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?

  Given a write tool with no annotations, no output schema, and 0% parameter coverage, the description should provide more context. It doesn't clarify file naming behavior, overwrite semantics, directory existence handling, or whether exports are visible/retrievable afterward. For a tool with two params and no structured supports, this is insufficiently complete.

  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?

  Schema description coverage is 0%, so the description must compensate. However, the description mentions none of the two parameters. 'latex_code' is implied by 'LaTeX resume source,' but 'filename' is entirely undocumented — its default behavior, constraints, or how it relates to the output directory is unclear. The description adds minimal value beyond what a reader might guess.

  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 states a clear verb+resource ('Save LaTeX resume source as a .tex file') with a specific destination ('the configured output directory'). While it doesn't explicitly distinguish itself from siblings, the verb 'save/export' clearly differentiates it from compilation, preview, and validation tools in the context. It's specific but lacks explicit sibling differentiation.

  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?

  There is no guidance on when to use this tool vs alternatives like compile_resume or preview_resume. The description doesn't mention whether export requires validation first, whether it works with saved templates, or any prerequisites. No exclusions, alternatives, or contextual cues are provided.

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

• validate_resumeC
  2.9/5.0
  Behavior2/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 transparency. It mentions validating for 'dangerous constructs' and 'structural issues' but doesn't disclose what happens on failure—does it return errors, suggestions, or modifications? Does it reject or just warn? No output format, no side effects, no granularity of validation level is disclosed.

  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?

  A single, efficient sentence that front-loads the verb and resource. No padding or filler. Could arguably be slightly more detailed, but the sentence earns its place and is appropriately compact.

  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?

  For a validation tool with no annotations, no output schema, and zero schema description coverage, the description does too little. The agent doesn't know what happens when validation fails or passes, what the return shape is, or how validation results are reported. Given the tool's complexity (validation implies rich feedback), this is incomplete.

  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 single parameter latex_code is straightforward and its name is self-explanatory as requiring the LaTeX source to validate. With 0% schema description coverage, the description doesn't add format details beyond what the schema name suggests, but for a single obviously-named param, minimal elaboration is needed. The baseline is somewhat lowered by zero coverage, yet the param name makes intent clear.

  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 verb (validate), resource (LaTeX resume source), and purpose (structural issues and dangerous constructs before compilation). It distinguishes from siblings like compile_resume and preview_resume by focusing on pre-compilation validation. Could be more specific about what 'structural' and 'dangerous' mean, but the core action is clear.

  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 when-to-use or when-not-to-use guidance is provided. It doesn't explicitly tell the agent to use this before compile_resume, nor does it describe what makes this preferable to compile_template or other siblings. The phrase 'before compilation' subtly implies ordering with compile_resume, but this is only implied, not explicit.

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

• preview_resumeB
  3.4/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. The description does disclose the compile action and what outputs are produced (metadata), which is adequate. However, it doesn't mention whether compilation is ephemeral, whether any files are persisted, authentication needs, or rate limits. For a tool that performs compilation, this is moderate coverage.

  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 a single efficient sentence that front-loads the purpose and enumerates the three key metadata outputs. Every word earns its place, with no fluff or redundancy.

  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 the tool has no annotations and no output schema, the description is the only source of behavioral information for the agent. It adequately covers purpose and return values but could benefit from stating side effects (does compile persist anything?), whether the compiled PDF is available for download, and how errors are surfaced for invalid latex_code. It's usable but not thorough for an unstructured tool.

  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 0%, so the description must compensate. The description adds context that latex_code is the input to compile and engine selects the compilation toolchain. However, it doesn't explain the effect of choosing xelatex vs pdflatex on resulting metadata, or any constraints on latex_code beyond the schema's minLength. The description name-checks the workflow but doesn't add depth beyond what's inferable from parameter names.

  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 a specific verb+resource ('Compile a resume') and specifies the exact output metadata it returns (page count, PDF size, compile duration). It distinguishes reasonably from siblings like compile_resume and export_tex by focusing on preview metadata rather than producing a file artifact, though it doesn't explicitly name those alternatives.

  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 this is for getting preview metadata (page count, size, duration) rather than producing the actual resume, which suggests when to use it. However, it doesn't explicitly state when NOT to use it or what the alternatives (compile_template, export_tex) are for, leaving the choice among siblings to inference.

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

• compile_resumeA
  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 discloses the engines used and what's returned (paths, logs), which is reasonable. However, it doesn't mention whether compilation failures throw errors vs return error logs, handling of missing latex_code, or whether the tool has side effects like writing files to disk (which would be relevant given no read-only annotations exist). The compiler-engine detail is useful 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?

  Two sentences, zero wasted words. Front-loaded with the core purpose. Could arguably drop 'using XeLaTeX (default) or pdfLaTeX' redundancy, but it's informative. Efficient and well-structured.

  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?

  With 3 parameters at 0% schema description coverage and no output schema, the description should do more. It covers the engine parameter well but leaves latex_code and filename semantics implicit. It doesn't describe error handling, compilation failure behavior, or how logs are structured. Adequate for a straightforward compile task but has gaps given zero annotations and 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?

  Schema description coverage is 0%, so the description must compensate for all three parameters. The description explicitly names the engines (xelatex, pdflatex) matching the schema enum and mentions the default, covering 'engine'. However, 'latex_code' and 'filename' are not explained beyond their names, though they are fairly self-evident. The engine semantic detail adds value beyond the schema.

  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?

  Description clearly states the verb (Compile), resource (LaTeX resume source), and output (PDF via XeLaTeX/pdfLaTeX). It specifies the compiler engines and return values (paths and logs). It distinguishes from siblings like preview_resume, though it doesn't explicitly say how it differs from compile_template.

  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 says it returns paths and logs and specifies default engine choice, but gives no when-to-use guidance versus alternatives. With siblings like compile_template, preview_resume, and export_tex nearby, explicit guidance on when to use this vs those would be helpful, but it's not misleading.

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

• versionA
  3.6/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 disclosure burden. The description states what data is returned (version, engines, SDK version, build info), which adds behavioral context. However, it doesn't disclose whether the tool makes network calls, requires authentication, or whether the data reflects the server or client. For a read-only informational tool with no annotations, the description provides reasonable but not exhaustive 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 a single, clear sentence that covers all return categories. It's efficient and contains no filler or redundancy. It earns a slight deduction from 5 because it could arguably enumerate what 'build information' means, but as written it's appropriately minimal and front-loaded with the main purpose.

  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 simple zero-parameter informational tool with no output schema and no annotations. Given this low complexity, the description specifying the four categories of returned data (version, engines, SDK, build) is reasonably complete. The definition adequately covers what an agent needs to know to decide when to invoke it and what to expect back, though it doesn't detail the return format structure.

  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's nothing the description needs to add about parameter semantics. Per the rubric, 0 params = baseline 4. The description appropriately lists the categories of information returned (version, engines, SDK, build), which is useful context even though no params exist.

  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 what the tool does: 'Return server version, supported engines, MCP SDK version, and build information.' It uses a specific verb (return) with a specific resource (server version/engines/SDK/build). While it doesn't need to differentiate from siblings (none of the siblings are version-related), the purpose is unambiguous and well-scoped.

  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 context (retrieve version/info when needed), but doesn't explicitly state when to use this vs alternatives or when not to. Given the sibling tools are all resume-related operations and this is an informational/metadata tool, the usage context is fairly obvious, but there's no explicit guidance about when to call it (e.g., 'call this to verify server compatibility or debug SDK mismatches').

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

• list_templatesA
  3.9/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 behavioral burden. 'List all installed' conveys a read-only, non-destructive action implicitly. The description tells the agent this returns template names plus their variable listings, which gives a useful preview of the return structure without needing error-path details for a simple listing operation.

  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, focused sentence with zero waste. It front-loads the verb ('List') and the object ('all installed resume templates') and then expands with the output detail ('and their variables'). Every part earns its place.

  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 zero-parameter listing tool with no output schema, the description is adequately complete. It tells the agent what the output will cover (templates + variables). Additional details like output format or pagination would be nice but aren't essential for a simple no-arg enumeration tool in the presence of rich sibling names that convey 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 has 0 parameters, so there are no schema details to document. The baseline for 0 params is 4. The description meaningfully states what the output covers (template names and their variables), which supplements the empty schema and gives the agent an accurate expectation of results.

  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 verb 'List' and resource 'all installed resume templates and their variables.' This distinguishes it from siblings like compile_template and compile_resume since it's a listing/introspection operation rather than a compilation or export operation. However, it doesn't explicitly differentiate from a hypothetical template-management sibling beyond the listing focus.

  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 this is a discovery/introspection tool — useful for learning what templates and variable names are available before calling compile/export tools. However, it doesn't explicitly state when to use this versus alternatives, nor does it name sibling tools or explain that it should be called before compiling a resume.

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