VA Form Generation MCP Server

Tool Scores

• get_fix_referenceC
  2.6/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. 'Get quick reference' suggests a read-only operation, but the description doesn't clarify what format the reference takes (text, structured data, examples), whether it's cached, if there are rate limits, or what happens with the 'all' option. Minimal behavioral context is provided beyond the basic operation.

  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 extremely concise at just 6 words, which is appropriate for a simple lookup tool. It's front-loaded with the core purpose. However, it's arguably too terse given the lack of context about what 'fixes' and 'reference' mean in this domain.

  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 tool with no annotations and no output schema, the description is incomplete. It doesn't explain what constitutes a 'fix' in this context, what format the reference takes, or what value this provides compared to sibling tools. The agent must guess the tool's role in the broader system of form/prompt tools.

  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 100% with a well-documented enum parameter, so the schema already provides complete parameter documentation. The description doesn't add any meaning beyond what the schema provides - it doesn't explain what 'fixes' are, what the reference contains, or how different fix_type values affect the output. Baseline 3 is appropriate when schema does the heavy lifting.

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

  Purpose3/5

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

  The description 'Get quick reference for common fixes' states a general purpose but lacks specificity about what resource is being referenced or what 'fixes' means in this context. It doesn't distinguish this tool from its siblings (audit_form, generate_orchestration_prompt, get_agent_prompt, validate_form) which all seem to relate to forms/prompts/validation. The description is vague rather than tautological.

  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 about when to use this tool versus alternatives. The description doesn't mention any prerequisites, context for usage, or relationship to sibling tools. The agent must infer usage from the tool name and parameter alone.

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

• audit_formC
  2.9/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 full burden. It states the tool audits and generates a fix report, implying a read-only analysis, but doesn't disclose behavioral traits like whether it modifies files, requires specific permissions, has rate limits, or what the output format entails. For a tool with no annotations, this leaves significant gaps in understanding its behavior.

  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 key actions ('Audit' and 'generate'). It avoids redundancy and wastes no words, though it could be slightly more structured by separating purpose from output details.

  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 no annotations and no output schema, the description is incomplete. It doesn't explain what a 'comprehensive fix report' includes, how results are returned, or any error handling. For a tool with 3 parameters and complex auditing functionality, more context is needed to guide the agent effectively.

  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 100%, so the schema fully documents parameters. The description adds no additional meaning beyond implying 'form_number' and 'workspace_path' are used for auditing, and 'pdf_path' for 'accuracy verification'. This meets the baseline of 3 since the schema handles parameter documentation adequately.

  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 ('Audit') and resource ('scaffolded VA form'), and specifies the output ('comprehensive fix report') and standard ('21P-601 best practices'). It distinguishes from siblings like 'validate_form' by focusing on auditing and generating fix reports rather than just validation. However, it doesn't explicitly contrast with all siblings (e.g., 'get_fix_reference').

  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 provides no guidance on when to use this tool versus alternatives like 'validate_form' or 'get_fix_reference'. It mentions 'scaffolded VA form' but doesn't clarify prerequisites, exclusions, or specific contexts. Without usage context, the agent must infer based on tool names alone.

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

• generate_orchestration_promptC
  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 disclosure. It mentions generating a prompt but doesn't explain what the prompt does, how it's used, or any side effects like permissions needed, rate limits, or output format. This leaves significant gaps for a tool that likely orchestrates complex agent workflows.

  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, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to understand at a glance.

  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 the complexity implied by orchestrating multiple agents and the lack of annotations or output schema, the description is insufficient. It doesn't explain what the generated prompt contains, how it's structured, or what happens after generation, leaving critical context gaps for effective tool use.

  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 100%, so the schema already documents all three parameters (form_number, workspace_path, pdf_path) with descriptions. The tool description adds no additional meaning or context about these parameters beyond what the schema provides, meeting the baseline for high coverage.

  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's purpose: 'Generate the full orchestration prompt to launch all 4 agents.' It specifies the action ('generate') and the resource ('orchestration prompt'), though it doesn't explicitly differentiate from sibling tools like 'get_agent_prompt' or 'audit_form'.

  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. The description lacks context about prerequisites, timing, or comparisons to sibling tools such as 'get_agent_prompt' or 'validate_form', leaving usage unclear.

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

• get_agent_promptC
  2.9/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 burden. It states it 'gets' a prompt, implying a read operation, but doesn't disclose behavioral traits such as whether it requires authentication, has rate limits, returns structured data, or handles errors. The description is minimal and misses key operational details.

  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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and every part contributes to understanding the action and scope, making it highly concise and well-structured.

  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 no annotations and no output schema, the description is incomplete. It lacks information on what the tool returns (e.g., prompt text, format), error handling, or any behavioral context. For a tool with 4 parameters and no structured output, more detail is needed to guide effective use.

  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 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond implying the agent number is 1-4, which is already covered by the enum in the schema. Baseline score of 3 is appropriate as the schema handles parameter documentation effectively.

  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 ('Get') and resource ('specialized prompt for a specific agent'), specifying the agent number range (1-4). It distinguishes from sibling tools like 'audit_form' or 'validate_form' by focusing on prompt retrieval rather than form validation or auditing. However, it doesn't explicitly differentiate from 'generate_orchestration_prompt' which might also involve prompts.

  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 'generate_orchestration_prompt' or other sibling tools. The description implies usage when needing a prompt for a specific agent, but lacks context on prerequisites, dependencies, or scenarios where this is preferred over other methods.

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

• validate_formB
  3.1/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 disclosure. It mentions the types of checks but doesn't cover critical aspects like whether this is a read-only operation, potential side effects, error handling, or performance implications. This leaves significant gaps for a validation 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 a single, efficient sentence with no wasted words. It front-loads the core action and lists key check types, making it easy to scan and understand quickly.

  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's moderate complexity (validation with multiple check types), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, results, or integration with siblings, leaving room for improvement in completeness.

  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 100%, so the schema fully documents both parameters. The description lists check types (schema, syntax, apostrophes), which partially aligns with the 'check_types' enum but omits 'imports' and 'all'. It adds minimal value beyond the schema, meeting the baseline for high coverage.

  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's purpose with a specific verb ('Run validation checks') and resource ('on a form'), and lists the types of checks (schema, syntax, apostrophes). It distinguishes the tool's function well, though it doesn't explicitly differentiate from sibling tools like 'audit_form'.

  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 provides no guidance on when to use this tool versus alternatives like 'audit_form' or other siblings. It lacks context on prerequisites, typical use cases, or exclusions, leaving the agent with no usage direction beyond the basic function.

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