Server Quality Checklist

Tool Scores

• ocd_get_contextsA
  3.5/5.0
  Behavior3/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 discloses the includeContent default and cwd usage for config discovery, but does not explicitly state read-only behavior, return format, or potential side effects. As a 'get' tool, read-only is implied, but lacking explicit disclosure and output details limits transparency.

  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-organized with a brief intro, parameter list, and jq filter examples. It is moderately sized and front-loaded, though some content (the jq examples) is example-oriented and could be trimmed without losing core meaning.

  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?

  With no output schema, the description should explain what the tool returns, but it does not describe the response structure or content. It covers parameter usage thoroughly but omits return value semantics, leaving agents uncertain about what to expect when calling the tool.

  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%, providing baseline 3. The description adds value by giving concrete examples for patterns (['project/**', 'docs/*']) and filter ('.attrs.status == "draft"') and clarifying the default for includeContent. This enriches the parameter semantics beyond the schema.

  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 states 'パターンとフィルタでコンテキストを取得します' (retrieves contexts with patterns and filters), which clearly identifies the operation as a retrieval using specific mechanisms. This distinguishes it from siblings like ocd_get_context_tree (tree retrieval) and ocd_search_contexts (search), though it doesn't explicitly name them.

  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 through examples of patterns and filters, but does not explicitly state when to use this tool versus alternatives. No exclusions or alternative recommendations are provided, leaving the agent to infer the appropriate context from the description and tool name.

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

• ocd_search_contextsA
  3.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 the full burden of behavioral disclosure. It only says it searches settings from cwd, but does not disclose recursive behavior, return format, case sensitivity, whether it searches file names or content, or any side effects. This is insufficient for a search 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, front-loaded sentence with no redundant words. Every word contributes to conveying the core purpose, making it appropriately concise.

  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?

  The tool has no output schema and no annotations, and the description is too thin to fill the gap. It does not explain what a 'context' is, what the search returns (e.g., context names vs. full objects), or how it fits with siblings like ocd_get_contexts. An agent would need more details to confidently invoke this tool.

  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 baseline is 3. The description adds no new parameter semantics beyond the schema; it merely restates the cwd concept ('cwd から設定を探索') that the schema already covers. No extra value is provided.

  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+resource: 'search contexts by keyword' and adds a qualifier about starting from cwd. This distinguishes it from sibling tools like list, get, mutate, and commit, so the purpose is 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 description implies usage for keyword-based search with cwd as the starting point, which is clear context. However, it does not explicitly mention when not to use this tool or name alternatives, though the distinct verbs of sibling tools make the intended use apparent.

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

• ocd_commitA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavior. It states 'commit changes' and 'search settings from cwd' but does not mention side effects (e.g., whether it pushes, stages, or rewrites history), nor does it explain what 'manual mode' entails or any required permissions. For a mutation tool, this is insufficient transparency.

  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 action and context. It contains no redundant words or filler, 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.

  Completeness3/5

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

  The tool is reasonably simple (commit with 3 params), and the description conveys the core intent. However, it omits important contextual details such as what 'manual' mode means, the effects of committing (e.g., does it also push?), and how it relates to the sibling context tools. It is minimally viable but not fully 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 description coverage is 100%, so the baseline is 3. The description adds no meaningful parameter semantics beyond the schema; the phrase 'cwd から設定を探索' merely restates the cwd parameter's existing description. No extra insight on 'paths' or 'message' is provided.

  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: '変更をコミット' (commit changes). It specifies the resource (git) and mode ('manual' モード用), and the scope (cwd-based settings search). It distinguishes from sibling context tools by using the verb 'commit'.

  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 '(git: 'manual' モード用)' provides clear context on when to use the tool: in manual git mode. It implies this is the explicit commit action as opposed to automatic modes. However, it does not name alternatives or provide exclusions beyond this implied context.

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

• ocd_list_context_rootsA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description should carry the behavioral burden. It warns that the returned path field is a filesystem path and should not be used as a tool argument, which is a useful behavioral detail. However, it doesn't disclose other aspects such as side effects, sorting, or error conditions, so it's adequate but not comprehensive.

  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 structured with a clear main sentence, followed by an important usage section with bullet examples, and a final note. It's a bit long but all content is actionable and not redundant.

  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 single-parameter read-only listing tool, the description covers the core purpose, usage of the returned value, and a critical caveat about path vs id. It's sufficient given the absence of an output schema, though it could mention the exact return structure more explicitly.

  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 describes cwd as the working directory starting point for config search, and the description reinforces this. Since schema coverage is 100%, the description adds minimal extra parameter semantics 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?

  The description clearly states the tool retrieves the list of context roots, and specifies it searches configuration from the cwd. It distinguishes this as the root-listing operation, separate from sibling tools like get_contexts or get_context_tree.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

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

  The description explicitly instructs how to use the returned ids with the sibling tools get_context_tree, get_contexts, and mutate_context, providing examples of parameter formats. This gives clear workflow guidance and distinguishes when to use this tool vs the alternatives.

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

• ocd_mutate_contextA
  4.1/5.0
  Behavior3/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 of behavioral disclosure. It explains path formatting, operation types, and title/summary rules, which are helpful. However, it does not disclose side effects, transactional behavior, permanence, or how the tool interacts with the separate ocd_commit sibling. For a mutation tool, this missing info is a notable gap.

  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 long but well-structured with headers, a table, and examples. The main purpose is front-loaded in the first line. Every section provides necessary operational detail, though it could be slightly trimmed without losing value. Overall it is efficient for the complexity it covers.

  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 tool is complex with 4 operation types and nested contentUpdates, and the description covers these thoroughly. However, it omits what the tool returns, error behavior, and how it relates to the ocd_commit sibling (e.g., are changes staged or immediately applied?). These omissions are significant given the lack of output schema and annotations.

  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 100% with descriptions for all parameters. The description adds substantial meaning beyond the schema: the operation type table clarifies required/optional fields, the path prefix rule is critical, the title/summary composition rules with examples are provided, and contentUpdates operation types are explained in detail. This significantly enhances correct parameter usage.

  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 opens with 'コンテキストを変更 (create/update/delete/move 一括実行)' which explicitly states the tool changes context and can execute multiple mutation operations in batch. It clearly distinguishes itself from sibling read/search/list tools by being the dedicated write tool.

  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 states '全ての書き込み操作を単一のツールで実行可能' (all write operations can be executed in this single tool), strongly implying this is the tool to use for any context mutation. It provides detailed operational constraints like path must start with Context Root id and required fields per operation type, but does not explicitly mention alternatives or when not to use. Sibling tools are read/commit focused, making the usage context clear.

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

• ocd_get_context_treeA
  4.5/5.0
  Behavior4/5

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

  The description discloses output formats (tree-text vs json), the default format, and the customizable display format using variables, adding behavioral context beyond the schema. It also mentions patterns takes precedence over depth, but does not address rate limits, authorization, or the exact return structure; with no annotations available, this is a moderate but not exhaustive disclosure.

  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-organized with separate sections for parameters, format, and display format, making it easy to scan. It includes necessary examples and warnings without excessive verbosity, though some information is redundant with the schema (e.g., cwd appears in both).

  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 has no output schema and no annotations, the description covers the essential aspects comprehensively: parameter usage, format selection, display format configuration, and important pitfalls. It even warns about using the wrong id type. Minor details like depth and maxNodes are only in the schema, but they are self-explanatory and do not hinder understanding.

  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?

  Although schema coverage is 100%, the description adds substantial value by explaining the relationship to list_context_roots and explicitly stating not to use the path field. It provides concrete examples for rootIds, describes patterns/exclude behavior, and elaborates on treeTextFormat variables and defaults, significantly enhancing the schema's brief parameter descriptions.

  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 'コンテキストツリー(目次)を取得' (get context tree/table of contents), which is a specific verb and resource. It differentiates from sibling tools like ocd_get_contexts by focusing on the tree structure, making the purpose 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 description provides explicit guidance to use IDs from list_context_roots and warns against using the path field, which is a critical usage instruction. It also explains that patterns overrides depth and gives concrete examples for single and multiple roots, but does not explicitly compare against sibling tools like ocd_get_contexts or mention when not to use this tool.

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