Server Quality Checklist

Tool Scores

• add_any_fileC
  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 full burden for behavioral disclosure. It states the tool adds files but doesn't describe what happens on conflicts (overwrites? errors?), permission requirements, side effects, or response format. For a mutation tool with zero annotation coverage, 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 the core purpose. There's no wasted verbiage, though it could be slightly more structured by explicitly separating purpose from constraints. It earns its place but isn't perfectly optimized.

  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 tool's complexity (file addition with mutation), lack of annotations, and no output schema, the description is insufficient. It doesn't cover error conditions, success indicators, or behavioral nuances like path validation. For a tool that modifies project state, more context is needed to use it 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%, with both parameters clearly documented in the input schema. The description adds no additional parameter semantics beyond implying 'chemin personnalise' (custom path) aligns with filePath. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.

  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 ('Ajouter' - Add) and resource ('n'importe quel fichier au projet' - any file to the project) with the specific capability of custom path specification. It distinguishes from siblings like add_java_file and add_resource_file by emphasizing 'any file' rather than specific types. However, it doesn't explicitly contrast with clear_project or create_maven_project.

  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 add_java_file or add_resource_file. It doesn't mention prerequisites (e.g., needing an existing project), exclusions, or comparative advantages. The agent must infer usage from the tool name and sibling names alone.

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

• add_java_fileC
  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 states the tool adds a Java file to a Maven project, implying a write operation, but doesn't cover permissions needed, whether it overwrites existing files, error handling, or what happens on success. This is inadequate for a mutation tool with zero annotation coverage.

  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 in French that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy to parse quickly.

  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 that performs a write operation (adding files) with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after the file is added, potential side effects, or error conditions, leaving significant gaps in understanding the tool's behavior and outcomes.

  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 description coverage is 100%, providing clear documentation for all 5 parameters. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 where the schema handles the heavy lifting without compensating for gaps.

  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 ('Ajouter' meaning 'Add') and the resource ('un fichier Java au projet Maven'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'add_any_file' or 'add_resource_file', which likely handle different file types in the same Maven project context.

  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. It doesn't mention when to choose 'add_java_file' over 'add_any_file' or 'add_resource_file', nor does it specify prerequisites or exclusions, leaving the agent to infer usage from the tool name alone.

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

• add_resource_fileC
  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 full burden for behavioral disclosure. It states this is an addition operation but doesn't mention whether this requires specific project state, what happens if the file already exists, permission requirements, or response format. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.

  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 sentence with zero waste - every word contributes to the core purpose. The description is appropriately sized for a straightforward tool and is front-loaded with the essential action and target.

  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 file creation/mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after file addition, error conditions, or how this integrates with the project structure. Given the complexity of file system operations and lack of structured safety hints, more behavioral context is needed.

  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 thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting for parameter documentation.

  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 ('Ajouter' = Add) and resource ('fichier de ressources' = resource file) with target context ('au projet' = to the project). It distinguishes from generic file addition tools like 'add_any_file' by specifying resource files, but doesn't explicitly differentiate from 'add_java_file' which might be a specialized case.

  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 use this tool versus alternatives like 'add_any_file' or 'add_java_file'. The description provides basic context (adding to a project) but doesn't specify prerequisites, constraints, or when other tools might be more appropriate.

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

• clear_projectC
  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. 'Vider' suggests a destructive action, but it doesn't disclose if this deletes files permanently, requires confirmation, affects only specific project parts, or has side effects. This is inadequate for a likely mutation tool with zero annotation coverage.

  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 in French, with no wasted words. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.

  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, no output schema, and a likely destructive action, the description is incomplete. It doesn't explain what 'clear' entails, what happens to the project, or what the user should expect afterward. For a tool with potential complexity and no structured support, this leaves significant gaps.

  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?

  There are 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info, which is fine here. Baseline is 4 for zero parameters, as the schema fully covers the absence of inputs.

  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 'Vider le projet en cours' (French for 'Clear the current project') states a verb ('vider' = clear) and resource ('projet en cours' = current project), giving a basic purpose. However, it's vague about what 'clear' means—does it delete files, reset configurations, or something else? It doesn't distinguish from siblings like 'list_files' or 'create_maven_project', which is a gap.

  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. For example, it doesn't specify if this should be used before creating a new project with 'create_maven_project' or after listing files with 'list_files'. The description implies a context ('current project') but offers no explicit when/when-not rules or prerequisites.

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

• create_maven_projectC
  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 states the tool creates a new Maven project but doesn't specify whether this is a destructive operation, what permissions are needed, where the project is created, or what happens on failure. This leaves significant gaps for a mutation 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 in French that directly states the tool's purpose without any fluff or redundancy. It's front-loaded and appropriately sized for its function.

  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 of creating a Maven project (a mutation operation), no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, error handling, and output expectations, making it inadequate for safe and effective use by an AI agent.

  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 7 parameters. The description adds no additional parameter semantics beyond implying standard Maven structure, which is already covered by the schema's detailed descriptions and defaults. This meets the baseline for high schema 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 action ('Creer un nouveau projet Maven vide') and the resource ('projet Maven'), specifying it creates a new empty Maven project with standard structure. However, it doesn't explicitly differentiate from sibling tools like 'set_pom_xml' or 'generate_zip', which might also relate to project creation or management.

  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. It doesn't mention prerequisites, when not to use it, or how it relates to sibling tools such as 'add_any_file' or 'clear_project', leaving the agent to infer usage context.

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

• generate_zipC
  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 states the tool generates and saves a ZIP file, implying a write operation, but doesn't cover critical aspects like whether it overwrites existing files, requires specific project structure, has side effects (e.g., modifying the project), or error handling. This leaves significant gaps for safe agent invocation.

  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 in French that directly states the tool's function without unnecessary words. It's front-loaded with the core action, making it easy to parse quickly.

  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 tool involves file generation and saving (a mutation operation), the lack of annotations and output schema means the description should compensate more. It doesn't explain what the ZIP contains (e.g., full project structure), success/failure responses, or dependencies on other tools. This is inadequate for a tool that modifies the filesystem.

  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 input schema has 100% description coverage, documenting the optional 'outputPath' parameter with its default value. The description adds no additional parameter semantics beyond what the schema provides, such as format details or constraints. Baseline 3 is appropriate since the schema does the heavy lifting.

  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 ('Generer et sauvegarder') and the resource ('le projet Maven en ZIP'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from siblings like 'create_maven_project' or 'add_any_file', which could also involve project handling, so it misses full sibling distinction.

  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. It doesn't mention prerequisites (e.g., needing an existing Maven project), exclusions, or how it relates to siblings like 'create_maven_project' for project creation or 'list_files' for checking project state.

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

• set_pom_xmlC
  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. While 'definir ou modifier' implies a write/mutation operation, it doesn't specify whether this overwrites existing content, requires specific permissions, has side effects, or how errors are handled. The description lacks critical behavioral context for a file modification 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 extremely concise with a single, clear sentence that states the tool's purpose without any unnecessary words. It's appropriately sized for a simple tool with one parameter and gets straight to the point.

  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 file modification tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens when the tool executes (does it validate the XML? does it backup the original file?), what the expected outcome is, or any error conditions. The context signals indicate this is a mutation tool, but the description lacks completeness for safe and 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?

  The description doesn't add any parameter semantics beyond what the schema already provides. With 100% schema description coverage (the 'content' parameter is fully documented in the schema), the baseline score of 3 is appropriate since the schema does the heavy lifting for parameter documentation.

  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 specific verbs ('definir ou modifier') and resource ('le contenu du pom.xml'), making it immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'add_any_file' or 'add_java_file', which might also modify files in a Maven project context.

  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. There's no mention of prerequisites, when this tool is appropriate versus other file modification tools in the sibling list, or any contextual constraints for its use.

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

• list_filesB
  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 states it lists files but doesn't describe what 'list' entails—whether it returns metadata, paths, or full contents; if it's paginated; or if it requires specific permissions. This leaves significant gaps for a tool that likely interacts with a project system.

  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 in French that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it highly concise and well-structured for its simplicity.

  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 tool's simplicity (0 parameters, no output schema), the description is minimal but adequate for basic understanding. However, it lacks context on behavior (e.g., output format, error handling) and doesn't leverage the absence of annotations to clarify operational details, making it incomplete for informed use.

  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 input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is appropriate here, but doesn't compensate for any gaps since there are none. A baseline of 4 is applied for zero-parameter tools.

  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 ('Lister tous les fichiers' - List all files) and the target resource ('du projet en cours' - of the current project). It uses a specific verb and identifies the resource scope, though it doesn't explicitly differentiate from sibling tools like 'generate_zip' or 'clear_project' which have different purposes.

  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. It doesn't mention prerequisites (e.g., needing an active project), exclusions, or comparisons to sibling tools like 'add_any_file' for adding files or 'clear_project' for removing them.

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