Server Quality Checklist

Tool Scores

• write_obsidian_noteC
  2.7/5.0
  Behavior2/5

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

  With no annotations, the description must fully disclose behavior. It only says 'Write' but does not state whether existing files are overwritten, directories are created, what happens if no active vault exists, or what the response contains. The vault_path parameter's effect is also undisclosed.

  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, succinct sentence with no redundant words, front-loading the verb and object. However, its brevity omits necessary context, which is a weakness rather than a strength in this case.

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

  Completeness1/5

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

  This tool has 3 parameters, no annotations, and an output schema that is not described. The one-sentence description fails to explain key operational aspects like vault_path's role, content formatting, overwrite behavior, or interaction with set_vault_path, making it unsafe for an agent to invoke correctly.

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

  Parameters1/5

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

  The description makes no mention of any parameter (content, note_path, vault_path). Since schema description coverage is 0%, the description provides no additional meaning beyond the schema's bare field names.

  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 action ('Write'), the object ('a markdown note'), and the destination ('into the active Obsidian vault directory'). This specific verb+resource combination differentiates it from siblings like set_vault_path and get_codebase_structure, even though siblings are not explicitly referenced.

  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. It does not mention prerequisites (e.g., setting the vault path) or exclusions. The word 'active' hints at prior configuration but is not explained.

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

• set_vault_pathB
  3.1/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavioral traits. It mentions 'session state' which implies a stateful, non-persistent change, but omits whether this overwrites the current vault, whether it requires filesystem access, or what the output schema contains. Lacks transparency about side effects and return behavior.

  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, front-loaded sentence that directly states the purpose. Every word is necessary; no redundant phrases or vague qualifiers. It is optimally concise for a simple setter tool.

  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?

  Despite having an output schema, the description omits important context such as preconditions, side effects, session state semantics, and how this tool fits with siblings. For a tool with no annotations and minimal schema info, the description is under-specified.

  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 coverage is 0% and the description adds little beyond the parameter name. 'Vault directory path' essentially restates the param name 'path' without specifying format (absolute/relative), existence requirements, or other constraints the schema does not cover.

  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 action (set) and the specific resource (active Obsidian vault directory path) and scope (session state). This distinguishes it from sibling tools like set_workspace_path, which targets a different resource.

  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 set_workspace_path, or any prerequisites (e.g., must the path exist? Should it be absolute?). The description only states what it does, not when to choose it.

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

• set_workspace_pathA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden. It only says 'Set' without disclosing side effects, path validation, persistence, or error behavior. For a mutation tool, this is a significant gap.

  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 redundant information, achieving high conciseness and clear front-loading.

  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?

  For a simple setter, the description covers the core purpose but omits guidance on when to use it over the sibling 'set_vault_path' and any path constraints. The existence of an output schema reduces the need to describe returns, but overall context is only partially 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?

  The schema has no descriptions (0% coverage), so the description adds meaning by identifying the purpose of the 'path' parameter as the workspace directory. However, it does not specify format, absolute/relative, or existence requirements, leaving room for improvement.

  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 action ('Set') and the specific resource ('active workspace directory path') tied to 'session state', distinguishing it from the sibling 'set_vault_path'. It is a specific verb+resource construction.

  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 one needs to establish the workspace directory for the session, but it does not explicitly state when to use this tool versus alternatives like 'set_vault_path'. No exclusions or conditions are provided.

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

• process_videoA
  3.7/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. It discloses the pipeline (audio extraction, Whisper transcription, keyframe extraction, JSON output) but does not mention potential side effects like output file creation, required external tools, or failure behaviors. This is adequate but not rich.

  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, front-loaded with the verb and resource, listing concrete steps and output. No redundant words, every part contributes to understanding.

  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 output schema exists (though not displayed), return values are covered. The description covers the main workflow but lacks guidance on when to use and parameter usage. For a moderate-complexity tool with no annotations, this is mostly complete with minor gaps.

  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%, yet the description does not explain the parameters (output_dir, vault_path, extract_frames) or how they relate to the described process. It only mentions the pipeline steps, leaving undocumented parameters, so the description fails to compensate for the low 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?

  Description clearly states the specific actions: extract audio, transcribe with Whisper, extract scene keyframes, and return a timestamp-aligned JSON payload. It names a specific verb ('process') and resource ('onboarding video'), and is clearly distinct from siblings like set_vault_path or write_obsidian_note.

  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 for onboarding videos but provides no explicit when-to-use or alternative statements. There is no mention of prerequisites, limitations, or cases where this tool should not be used. The context is clear enough, but no exclusions or alternatives are given.

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

• get_codebase_structureA
  3.8/5.0
  Behavior4/5

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

  It discloses key behaviors: recursive scanning and respecting .gitignore, which are non-obvious and helpful. It implies a read-only operation by saying 'scan and return', but does not explicitly state that no files are modified or mention performance limits. With no annotations, this is moderately 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?

  One sentence of 12 words, front-loaded with 'Recursively scan' and no filler. It is efficient and easy to parse.

  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 main functionality and the output schema handles return values, so those aspects are complete. However, it omits how the optional workspace_path behaves when null or unset, leaving a gap for a parameter-driven tool. A brief note on default path would complete it.

  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?

  The schema provides no description for workspace_path (0% coverage). The description only refers to 'workspace directory', which essentially restates the parameter name without explaining behavior when null, required format, or default path. It does not compensate for the lack of schema 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 action ('recursively scan workspace directory') and output ('file tree and dependencies'), while also specifying respect for .gitignore. This distinguishes it from sibling tools like set_workspace_path, process_video, and write_obsidian_note, 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 Guidelines3/5

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

  The description explains what the tool does but does not explicitly state when to use it or when to prefer alternatives. There is no mention of prerequisites or exclusions, so usage context is only implied by the action itself. Given sibling tools, this could benefit from a simple 'use this when you need to explore the codebase layout'.

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