Server Quality Checklist

Tool Scores

• extract_assetsA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description must fully disclose behavior. It mentions extraction and returns a dictionary, but fails to state whether the operation is read-only, what happens on failure, or prerequisites (e.g., file existence). It does not disclose potential side effects or error conditions.

  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 well-structured with a one-line summary, detailed Args/Returns, and an example. It is slightly verbose due to duplicating information that could be in the output schema, but the front-loading of the main purpose is effective.

  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 description covers the core functionality, inputs, and outputs, including an example. However, it lacks details on error handling, timeout behavior, and prerequisites. The default inconsistency also indicates incomplete specification.

  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 adds meaning to the schema, explaining swf_path, output_dir, asset_types (with valid values), and timeout. However, it contradicts the schema defaults: description says asset_types default ['all'] and timeout default 60, while schema shows null defaults. This inconsistency undermines clarity.

  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 'Extract' and the resource 'assets from a SWF file', specifying asset types (images, sounds, fonts, etc.). It distinguishes itself from sibling tools like extract_actionscript (code) and decompile_swf (full decompilation), making its purpose immediately clear.

  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 does not explicitly state when to use this tool over alternatives. While it implies it is for non-code assets, it lacks guidance like 'Use this when you need assets only, not code.' The sibling tool names provide context, but the description itself falls short of clear usage boundaries.

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

• decompile_swfA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description discloses the decompilation process, output structure, and timeout option. It does not mention error handling for corrupted files, but the behavior is sufficiently clear for a read-only analysis 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 well-structured with a summary, detailed paragraph, args, returns, and an example. Every sentence is valuable and efficiently conveys necessary information.

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

  Completeness5/5

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

  Given the presence of an output schema, the description covers inputs and outputs thoroughly, and the sibling tools are distinct. No additional context is needed for effective use.

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

  Parameters5/5

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

  Schema coverage is 0%, but the description fully explains all three parameters in the Args section, including types, purposes, and optional defaults, adding substantial meaning beyond the raw schema.

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

  Purpose5/5

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

  The description clearly states the tool decompiles all ActionScript code from a SWF file, specifying the resource, action, and output structure. It distinguishes from siblings like 'extract_assets' and 'list_symbols' by focusing on full code decompilation.

  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 provides an example but no explicit guidance on when to use this tool versus siblings like 'extract_actionscript' or 'get_swf_metadata'. Usage context is implied but not directed.

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

• deobfuscateA
  4.4/5.0
  Behavior5/5

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

  With no annotations provided, the description fully discloses behavioral traits: it runs FFDec's algorithms, removes dead code/traps/anti-decompilation tricks, and produces a cleaner SWF. It also explains the level parameter options and timeout, providing comprehensive insight into the tool's 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 well-structured with sections for Args, Returns, and an Example. It is front-loaded with purpose, but the example, while helpful, adds length. Overall, it is efficient and organized, though slightly verbose.

  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 absence of annotations and the presence of an output schema, the description covers the tool's behavior, parameters, return values, and provides a usage example. It lacks details on error handling, prerequisites, or performance considerations, but is sufficiently complete for a deobfuscation tool.

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

  Parameters5/5

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

  The input schema provides no descriptions (0% coverage). The description adds full meaning to each parameter: swf_path and output_path are clearly defined, level lists three allowed values with defaults, and timeout includes default. The example further clarifies usage, fully compensating for the schema's lack of documentation.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Deobfuscate a SWF file by removing obfuscation techniques.' It specifies the verb 'deobfuscate' and the resource 'SWF file', and distinguishes from sibling tools like decompile_swf or extract_actionscript by focusing on removing obfuscation rather than decompilation or extraction.

  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 when a SWF file is obfuscated, but does not explicitly state when to use this tool versus alternatives. It does not mention any conditions or exclusions, leaving the agent to infer context from the tool name and sibling tools.

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

• extract_actionscriptA
  4.4/5.0
  Behavior4/5

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

  No annotations provided, but description discloses behavior: extracts AS3 classes only, returns structured dict with success info. Doesn't mention side effects or destruction, but as a read-like operation, it's adequate.

  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?

  Well-structured with Args and Returns sections and an example. Slightly verbose but front-loaded with purpose. Every section adds value.

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

  Completeness5/5

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

  Covers all parameters, return values, and provides an example. Complex tool with 4 params and 3 required, but description fully addresses usage. Output schema exists but description still includes return details.

  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 0%, but description provides detailed parameter descriptions (e.g., 'fully-qualified class names', 'optional timeout'). Adds meaning beyond schema types.

  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?

  Clearly states it extracts specific ActionScript classes by name from a SWF file, distinguishing it from full decompilation. The verb 'extract' and resource 'ActionScript classes' are specific and differentiate from siblings like decompile_swf.

  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?

  Explicitly says it's 'faster than full decompilation when you only need specific classes', which guides when to use. No explicit exclusions, but context implies when not to use (if full decompilation needed).

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

• list_symbolsA
  4.5/5.0
  Behavior4/5

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

  No annotations, but description thoroughly explains behavior, return format, and that it's a non-destructive read operation. Lacks mention of error conditions but is sufficient.

  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?

  Well-structured with header, args, returns, and example; each section adds value without redundancy.

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

  Completeness5/5

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

  Fully explains the tool's purpose, single parameter, and detailed return structure; output schema exists, so no need to describe return values further.

  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 only specifies type string; description adds 'Absolute path to the SWF file' and provides an example, enhancing clarity beyond the schema.

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

  Purpose5/5

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

  Clearly states it lists ActionScript classes and symbols without decompiling, contrasting with sibling tools like decompile_swf and extract_actionscript.

  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?

  Explicitly suggests using 'before full decompilation' and contrasts with siblings, but could more directly state when not to use.

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

• get_swf_metadataA
  4.6/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. It fully discloses the operation: reads header, no decompilation, returns metadata. It does not discuss permissions or side effects, but given the read-only nature implied, it is adequate.

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

  Conciseness5/5

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

  The description is well-structured with clear sections (description, args, returns, example). It is concise, front-loaded with purpose, and each sentence adds value.

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

  Completeness5/5

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

  Given the low parameter count and the tool's simplicity, the description is complete. It includes return fields in the description even though no output schema is provided, ensuring the agent knows what to expect.

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

  Parameters5/5

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

  The single parameter swf_path is described as 'Absolute path to the SWF file', adding meaning beyond the schema which only states type string. Schema coverage is 0%, so description fully compensates.

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

  Purpose5/5

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

  The description clearly states the tool extracts metadata from a SWF file header, specifying exact fields (dimensions, frame rate, etc.). It distinguishes from sibling tools like decompile_swf by noting it is fast and doesn't require decompilation.

  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 implies usage for quick metadata retrieval without decompilation, providing clear context. However, it does not explicitly state when to use this tool versus siblings or list alternatives, though the context is strong.

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