Server Quality Checklist

Tool Scores

• get_retention_mechanicsA
  3.8/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 responsibility for behavioral disclosure. The description only lists the content and does not mention any behavioral traits such as read-only nature, side effects, authentication requirements, rate limits, or return format. For a simple info-retrieval tool this is a minor gap, but it remains undisclosed.

  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 sentence that front-loads the key information (the 6 mechanics), lists them parenthetically, and summarizes the added value (application and failure risk). Every word earns its place with no redundancy or fluff.

  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 simplicity of the tool and the presence of sibling tools that cover other topics, the description is complete for a knowledge-retrieval tool. It clearly states what content is included (mechanics, application, failure risk). It does not specify output format, but no output schema exists and the content scope is sufficiently defined.

  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 and the schema coverage is trivially 100%. Per the rubric, a baseline of 4 is appropriate when there are no parameters, and the description does not need to add parameter semantics. No conflicts or gaps exist.

  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 identifies the tool as providing the 6 retention mechanics, enumerates them, and specifies the included information (application and failure risk). This distinguishes it from sibling tools like get_hook_mechanics (hooks vs. retention) and get_cta_rules (calls to action), making the purpose unmistakable.

  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?

  Usage context is implied by the tool's name and content: it is for when you need to know retention mechanics. However, there is no explicit guidance about when to prefer this over alternatives, no exclusions, and no mention of when not to use it. The description does not reference sibling tools or provide decision criteria.

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

• get_script_structureA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden for behavioral disclosure. It indicates a read-only retrieval action ('Get') and describes the output content (beat-by-beat timings and rules). However, it does not explicitly state that it has no side effects, require permissions, or handle invalid formats. The word 'Get' implies safety but lacks detail.

  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 two sentences with no extraneous words. The main action is front-loaded, and the second sentence adds a meaningful detail about the output. It is appropriately sized for a simple one-parameter tool.

  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?

  This is a simple read-only tool with one parameter and no output schema. The description fully covers the purpose, the input domain, and what the output will contain (structure with timings and rules). No further context is needed for an agent to select and invoke the tool correctly.

  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 schema provides the format enum, but the description adds meaning by explaining that the parameter selects a format's specific script structure and that each format includes 'rules that keep the format working.' It also reiterates the valid format values in prose, reinforcing the parameter's purpose and scope.

  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: to retrieve the beat-by-beat script structure with timings for a specific format. It explicitly lists all five valid formats, making the resource and scope clear. This distinguishes it from sibling tools like get_hook_mechanics or get_retention_mechanics, which focus on specific elements.

  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 explicit guidance on when to use this tool versus alternatives. It does not mention situations where you would choose this over audit_script or get_full_pack, nor does it state any exclusions or prerequisites. The tool's use case is only implied by its name and description.

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

• audit_hookA
  4/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 full burden of behavioral disclosure. It transparently states the evaluation criteria and the return format (PASS/NEEDS WORK with named issues). While it doesn't explicitly say it's read-only or detail side effects, the audit nature is clear and the output is described. This goes beyond a minimal 'audits a hook' statement.

  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, information-dense sentence. It front-loads the verb and resource, lists specific checks, and mentions the output format. Every phrase adds value; there is zero fluff or redundancy.

  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 tool with one parameter and no output schema, the description explains what is checked and what the return looks like. It doesn't detail the structure of 'named issues' or provide examples, but the key information is present. Given the low complexity and the richness of the description, it is adequately 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% and the only parameter 'hook' is described as 'The hook line as it would be spoken or captioned.' The description adds behavioral context about the audit but does not add additional parameter-level meaning beyond what the schema already provides. Baseline 3 is appropriate given high schema coverage.

  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 a specific verb 'Audit' with a specific resource 'hook line', and enumerates exactly what checks are performed (length vs 2-second window, greeting openers, hype words vs receipts, specificity, style). This distinguishes it from sibling tools like audit_script, which audits a full script, and get_hook_mechanics, which likely provides mechanics rather than performing an audit.

  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 tool is used to audit a hook line, which is clear context. However, it provides no explicit guidance on when to choose this tool over siblings like audit_script or get_hook_mechanics. There are no stated exclusions or alternative recommendations, so guidance is only implied.

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

• audit_scriptA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It clearly describes the tool's behavior: it audits the script and returns a verdict with hook sub-audit and format beats. It also discloses the checks performed. There are no destructive actions or auth requirements to mention, and the output is described, making this appropriately transparent.

  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, front-loaded with the main purpose, and each clause adds value. No fluff or repetition of schema fields. The return structure is mentioned efficiently.

  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 tool's moderate complexity (2 params, no output schema), the description covers the main purpose, the evaluation criteria, and the return value. It could mention an example or clarify that it doesn't modify the script, but overall it is sufficiently complete for an agent to use it correctly.

  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 50%: only 'format' has a description. The description adds context for 'format' by mentioning 'format beats for comparison', but does not explicitly map to the parameter. 'script' is self-evident and required, but lacks any schema description. The description partially compensates but could be more explicit about how 'format' influences the audit.

  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 it 'Audit a full short-form script' and lists the specific dimensions checked (hook quality, spoken length, single-CTA rule, hype vs receipts, zero-numbers check). This distinguishes it from sibling tools like 'audit_hook' by emphasizing 'full script' and the included hook sub-audit.

  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 context is implied: it's for full-script audits, with format comparison. However, it does not explicitly state when to use this over alternatives like 'audit_hook' or 'get_script_structure', nor does it mention any exclusions or prerequisites. The guidance is present but not explicit.

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

• get_hook_mechanicsA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It explains the output format ('fill-in structures') and the content type returned (why each works, failure mode, suitable content type), which is transparent for a read-only get tool. It does not mention side effects, which are not expected for such a 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 compact and front-loaded, with the core purpose stated first, followed by a list of styles and the optional filter. Every sentence earns its place, and the list improves scannability without padding.

  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?

  For a simple get tool with one optional parameter and no output schema, the description is complete. It specifies exactly what the tool returns (10 styles, each with fill-in structure, rationale, failure mode, and content fit) and how to narrow results. No additional 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?

  The schema already covers the single parameter 'style' with an enum and description, giving 100% schema coverage. The description adds only that filtering is optional ('Optionally filter to one style'), which is minimal additional value over 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?

  The description clearly states the tool's function: 'Get the 10 hook styles as fill-in structures with why each works, its failure mode, and what content type it fits.' It uses a specific verb and resource, and enumerates all ten styles, making it distinct from sibling tools like audit_hook or get_script_structure.

  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 the tool is for retrieving hook mechanics and offers an optional filter ('Optionally filter to one style'), which gives clear usage context. It does not explicitly name alternative tools or provide when-not-to-use guidance, but the context is clear enough.

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

• get_cta_rulesA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses that each goal entry includes the rule, placement, and the one-CTA-per-video law, which clarifies the return content. It doesn't explicitly state that omitting the goal returns all rules, but the enum and optional schema parameter make that reasonably inferable, and this is a read-only getter by name.

  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?

  A single, compact sentence that front-loads the purpose ('CTA rules by goal') and then lists the goals and content structure. Every word earns its place; there is no fluff or 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?

  Given the tool's simplicity—one optional parameter, no output schema, and clear sibling differentiation—the description is complete. It covers valid goals, what each rule includes, and the core constraint (one-CTA-per-video). No additional context is necessary for an agent to select and invoke this tool correctly.

  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 100% with an enum, so the baseline is 3. The description adds value by explaining what each goal entry contains (rule, placement, law), which is beyond the schema's straightforward parameter description. This enriches the semantics without repeating 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?

  The description immediately identifies the tool as providing CTA rules categorized by goal, listing the specific goals (follow, comment_seed, lead_magnet, product, save_share). This is a specific verb+resource combination that clearly distinguishes it from sibling tools focused on hooks, scripts, retention, and audits.

  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 when to use it—when you need CTA rules for a particular goal—by enumerating the goals. It doesn't explicitly name alternatives or say when not to use it, but the sibling tool names provide sufficient context, and the clear goal list acts as an implicit usage guide.

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

• get_full_packA
  4.5/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 burden of explaining behavior. It discloses the scope of the payload (hook styles, script formats, retention mechanics, CTA playbook) and implies it returns comprehensive content. While it doesn't detail return format or volume, it gives sufficient behavioral context for a simple, read-only get 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 two sentences long, front-loaded with the tool's purpose, and every word adds value. It efficiently lists contents and the intended use case without unnecessary elaboration.

  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?

  For a no-parameter aggregate getter with no output schema, the description is complete: it names all content categories included and clarifies the use case. Sibling tools provide contrast, and the empty parameter list means no additional input context is needed.

  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, and the schema is empty, so the baseline for parameter semantics is 4. There are no parameter descriptions needed, and the description appropriately focuses on the tool's output rather than inputs.

  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 retrieves a 'complete content-mechanics library' and enumerates the included components (hook styles, script formats, retention mechanics, CTA playbook). This distinguishes it from sibling tools that focus on individual mechanics, making its purpose 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 Guidelines4/5

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

  The phrase 'For full agent context' provides a clear context for when to use this tool, implying it should be used when comprehensive knowledge is needed rather than individual components. It doesn't explicitly name alternatives or exclusions, but the intended use is evident.

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