Server Quality Checklist

Tool Scores

• archimate_vs_togafC
  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 the full burden of disclosure. It says what the tool is about but not what the tool does behaviorally — whether it returns a static explanation, generates a tailored comparison, or has side effects. The absence of any mention of output format, prerequisites, or limitations leaves the agent to infer that this is a read-only informational query.

  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 appropriately sized and front-loaded with the core concept ('棲み分け' / how they relate). Each listed topic earns its place, and the bilingual format, while duplicative, serves a multilingual audience. The English portion is dense and well-organized with a clear progression from roles to usage to pitfalls to minimal combination.

  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 tool with one optional parameter and no output schema, the description covers the key content areas well enough for an agent to understand the tool's scope. However, it lacks behavioral context such as the type of response (explanatory text, structured summary, etc.) and any limitations. Given the simple nature of the tool, this is adequate 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?

  The only parameter, lang, is fully documented in the schema with an enum, a default, and a bilingual description, so schema coverage is 100%. The tool description adds no extra meaning about the lang parameter, which is acceptable because the schema already covers it. The baseline of 3 applies here since the description does not need to compensate for schema 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 subject (TOGAF vs ArchiMate) and the specific aspects covered: role distinction, when to use which, common mistakes, and minimum combination. The verb 'relate' and the phrase 'how combining them goes wrong' make the tool's function understandable. It does not explicitly name sibling tools like compare_with_togaf or map_togaf_to_archimate, so differentiation is not fully explicit, but the conceptual focus is distinct.

  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 includes 'when to reach for which' as a topic, but this refers to choosing between TOGAF and ArchiMate, not to when this tool should be selected over sibling tools. There is no explicit guidance about what kind of request should route here versus to compare_with_togaf, map_togaf_to_archimate, or reference. Use cases are implied only by the subject matter.

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

• capability_methodB
  3.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full disclosure burden. It discloses the output structure well — eight steps each with output, failure mode, and effort, plus L1/L2/L3 criteria and single-step filtering — which clearly signals a read-only informational tool. However, it never states the return format (plain text, markdown, etc.) or behavior for out-of-range step values, leaving some behavioral ambiguity.

  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?

  Three short sentences front-loaded with the core purpose; the bilingual duplication is justified by the lang parameter supporting ja, en, and both. There is no filler, and each sentence carries distinct information.

  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 informational tool with no output schema and no annotations, the description covers the critical facts: what the method contains, how to filter to a single step, and what the granularity guide includes. The only missing piece is an explicit statement of the return format, which is minor given the tool's nature.

  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's parameter references ('Pass step for a single step', 'Includes L1/L2/L3 granularity criteria') largely restate what the schema already documents for step and includeLevels, adding no new semantic detail 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 a specific action ('Return an eight-step method for building a business capability map') and adds concrete content detail (each step has output, failure mode, and effort). It implicitly differentiates from siblings like draft_capability_map and check_capability_map by framing itself as a how-to method rather than a map generator or validator, but it never names those alternatives explicitly.

  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 choose this tool over closely related siblings such as draft_capability_map, check_capability_map, or the analogous value_stream_method. The only usage instruction, 'Pass step for a single step,' is about parameter invocation, not tool selection. With such a large sibling set, the absence of routing guidance is a real gap.

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

• start_engagementB
  3.2/5.0
  Behavior3/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 does reveal that the tool initializes and persists ADM phase progress and that overwrite=true replaces an existing engagement, which is important destructive behavior. However, it doesn't clarify whether the tool creates a new engagement or modifies an existing one, what side effects occur, or how it differs from create_engagement/update_engagement.

  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 concise and front-loaded with the core action and the critical overwrite condition. It contains no filler, though the bilingual repetition is a minor inefficiency that doesn't detract much.

  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 has 8 parameters, no annotations, and no output schema, the description is too brief to be fully contextual. It leaves key ambiguities: whether an engagement must already exist, what happens if overwrite is not set, what the return value is, and how this tool relates to create_engagement and update_engagement. An agent may not be able to call it correctly without additional inference.

  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 description coverage is 100%, so the baseline is 3. The tool description adds value by specifying when overwrite=true is required ('if there is an existing engagement'), which is not explicitly stated in the parameter description. It also implicitly connects the currentPhase parameter to the 'initialize ADM phase progress' behavior.

  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 specific actions: start an engagement, initialize ADM phase progress, and persist it. It also adds the overwrite behavior for existing engagements. However, it does not explicitly differentiate itself from sibling tools like create_engagement or update_engagement, leaving some room for ambiguity.

  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 vs alternatives such as create_engagement or update_engagement. It does mention that overwrite=true is needed for existing engagements, which is a partial usage condition, but there are no exclusions, prerequisites, or alternative routing.

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

• export_deliverableB
  3.4/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 behavioral burden. It discloses the side effect of writing a file and the auto-filled engagement name, which is useful. However, it does not state overwrite/collision behavior, whether the knowledge base is modified, or what the tool returns on success or failure.

  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 short bilingual sentences that front-load the main action and then add the auto-fill behavior. There is no filler and no repetition of schema field names.

  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?

  There is no output schema and no annotations, so the description must cover call expectations; it leaves out return values, overwrite-when-false behavior, and prerequisites such as a current engagement existing. The parameter schema is complete, but tool-level context is only partially described.

  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 parameter baseline is 3. The description adds context that the output is a Markdown skeleton and that the engagement name comes from the current engagement, which aligns with engagementName, but it adds no parameter syntax 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 states a specific action ('write ... to a file'), a specific resource ('Markdown skeleton of a knowledge-base deliverable'), and the file destination. The phrase 'to a file' also separates it from generate_deliverable_template and export_report without needing to inspect their schemas.

  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 when-to-use or when-not-to-use guidance is given. The description explains that the engagement name is auto-filled, but never tells the agent to prefer this over generate_deliverable_template or export_report. The only implied usage is from the tool title.

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

• generate_deliverable_templateB
  3.4/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 usefully discloses that the output is a Markdown skeleton with section structure and filling guide, and that data is pre-filled from the current engagement by default. It does not state whether the tool persists anything, only returns text, or what happens when deliverable is omitted.

  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 bilingual description is compact: each language version is a single sentence that states the resource, the main behavior, and the default pre-fill. No filler or repetition beyond the intentional bilingual duplication.

  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 tool with no output schema and no annotations, the description covers the resource and default behavior but leaves gaps: no usage route versus siblings, no explicit statement about side effects or persistence, and no description of the listing behavior when deliverable is omitted. It is adequate but not complete enough for an agent to make a fully informed choice.

  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?

  All four parameters have schema descriptions, so the baseline is 3. The description adds semantic value by enumerating exactly which engagement data gets injected (stakeholders, risks, work packages, transition states), which clarifies useEngagement and engagementName 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 names a concrete verb ('Generate') and resource ('Markdown skeleton for a deliverable') and specifies the default pre-fill behavior. It does not explicitly distinguish itself from near siblings like export_deliverable or generate_review_checklist, so it falls short of a 5.

  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 given about when this tool is preferred over alternatives such as export_deliverable or draft_capability_map, nor are exclusions or prerequisites stated. The only contextual hint is the default pre-fill behavior and the useEngagement=false escape hatch, which is parameter behavior, not usage guidance.

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

• diagram_adm_cycleA
  3.5/5.0
  Behavior3/5

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

  The description discloses the key behavioral trait: it automatically reflects engagement progress if an engagement exists, otherwise uses arguments. It also states it lists what to do in the current phase below the diagram. With no annotations, more behavioral details such as output limitations or rendering specifics could be added, but the main behavior is clearly disclosed.

  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 compact, bilingual, and provides essential information in two sentences. It front-loads the main purpose and then adds the engagement-aware behavior and output contents without excessive detail.

  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 diagram generation tool with no required parameters, the description covers what the diagram includes, how data is sourced, and what is appended. It is reasonably complete, though it does not mention whether a specific output schema or further rendering options are available.

  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 description references the argument fallback but does not elaborate on parameter semantics beyond the schema. The schema already describes completed, currentPhase, and lang, so the description adds minimal additional meaning.

  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 draws the ADM cycle as a Mermaid diagram with Requirements Management at the centre, phase statuses colour-coded, and the current phase highlighted. It is distinct from other diagram tools like diagram_capability_map, though it could more explicitly name a sibling alternative.

  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 that the tool uses the current engagement when one exists, otherwise falls back to the arguments, which implies when to call it versus providing explicit parameters. However, it does not state when to prefer this over other diagram tools or what conditions make it inappropriate.

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

• risk_matrixA
  3.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 full burden and does substantial work: it discloses that the tool visualizes stored data, flags specific risk categories, includes a source column with a legend, and aggregates traceable entries as 'N/M 件'. While it does not explicitly state that no data is modified, the phrasing 'Plot' and 'visualize' strongly indicates a read-only 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 compact yet information-dense, covering purpose, outputs, and specific flagging behavior in two sentences per language. Bilingual duplication slightly increases length, but each part contributes meaningful detail about behavior and output, so nothing is wasted.

  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 tool with one optional parameter and no output schema, the description is largely complete: it explains what is plotted, what is flagged, and what the detail table contains. The main gap is not stating whether it operates on the current engagement specifically or how it is selected, but the low complexity and rich behavioral detail keep this from being a major omission.

  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% for the single lang parameter, which already documents the allowed values and default. The description does not add extra parameter-level meaning beyond the schema, so 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 tool's specific purpose: plotting stored engagement risks as two matrix types (level × status, current × residual) and flagging attention items. It names concrete outputs such as unassessed residual risk, missing owners, and severe risks without mitigation. However, it does not explicitly differentiate itself from the sibling diagram_risk_matrix, so it is clear but not fully differentiated.

  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 implies usage context by saying it 'flags what needs attention' and describes the output, but it gives no explicit guidance about when to choose this tool over alternatives. In particular, sibling diagram_risk_matrix appears closely related, and the description does not explain the difference or when to use one versus the other.

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

• get_engagementA
  3.6/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 and does substantial work: it discloses that Markdown output is automatically trimmed for large engagements, states that format='json' returns the complete raw JSON, and explains how compact and limit override/control trimming. This is meaningful non-obvious behavior beyond the schema.

  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 front-loaded with the core action and then details formatting behavior. It is relatively dense and bilingual, but the extra length is justified by the tool's non-trivial output behavior and the bilingual audience.

  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 low-complexity retrieval tool with no required parameters and no output schema, the description covers the main behavioral context: output format, trimming behavior, and row-count controls. It does not explain what 'the engagement' contains or error cases, but the essentials for calling and interpreting results are present.

  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 description coverage is 100%, so the baseline is 3, but the description adds value by explaining behavior tied to parameters: format='json' yields complete raw JSON, compact=false shows every row, and limit changes the row count. This goes beyond the schema's per-parameter descriptions.

  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 uses a clear verb and resource: '保存されているエンゲージメントの内容を返す' / 'Return the stored engagement'. It is distinguishable from list_engagements and other engagement tools by focusing on the current/stored engagement, though it does not explicitly name any sibling alternative.

  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 gives useful within-tool guidance for format, compact, and limit options, but it provides no guidance on when to choose this tool versus siblings like list_engagements, switch_engagement, or check_engagement_health. No alternatives or exclusions are mentioned.

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

• open_dashboardA
  3.6/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 transparency burden. It goes beyond a generic 'open dashboard' statement by disclosing that it starts a local HTTP server, live-updates over SSE, and includes print CSS. It does not cover server lifecycle or response structure, but the core behavior is well exposed.

  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 concise and front-loaded with the main action, then adds useful behavioral details (SSE, print CSS). The bilingual duplication is necessary for the audience and every sentence contributes information without fluff.

  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?

  Given no annotations and no output schema, the description is the main source of context. It explains the core behavior and says a URL is returned, but it does not specify the response format or clarify behavior when open=false, such as whether the server still starts. These are minor gaps for a simple tool but prevent a higher score.

  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 covers 100% of parameters with type, enum, default, and descriptions, so the baseline is 3. The tool description adds little parameter-specific meaning beyond implying that 'open' relates to launching a browser; the schema already handles the details.

  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 starts a local HTTP server on 127.0.0.1, opens the live dashboard in a browser, and returns the URL. This is a specific verb+resource action that differentiates it from sibling 'get_dashboard', though it does not explicitly name that alternative.

  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 usage context is implied: use when the user wants the live dashboard opened in a browser. However, there is no explicit guidance on when to use this tool versus alternatives like get_dashboard or open_start, and no exclusions or prerequisites are given.

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

• consultA
  3.7/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden, and it does disclose meaningful behavior: constraints in the text (budget, deadline, executive engagement, staffing) change the recommendations, and topics marked off the table are excluded from the read. It does not describe its input-visibility limitation, but that is covered in the schema's readings parameter.

  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 compact: two short sentences per language, with the output components front-loaded before the adaptive behavior. The bilingual duplication is mild and consistent with the lang=both default, so it does not harm structure.

  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?

  There is no output schema, so the description usefully enumerates the six returned components. The complex readings object is fully documented in the schema, and the description covers the core contract, leaving only sibling differentiation as a real gap.

  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%, and every parameter, including the nested readings axes, has a description. The tool description adds no parameter-specific semantics beyond restating constraint categories that the situation schema already mentions, so the baseline 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 names a specific action — free-text situation in, TOGAF-based read out — and enumerates the concrete output components (diagnosis, phases, techniques, deliverables, actions, stakeholder questions). It is clear and useful, though it does not explicitly differentiate itself from related siblings such as next_best_action or assess_readiness.

  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 use case: when an architectural situation needs a TOGAF-based read and the user can supply constraints in free text. It gives no when-not guidance and does not point to any sibling alternative, so an agent gets only implicit selection help.

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

• diagram_risk_matrixA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses the return format (table + Mermaid quadrant chart), the precedence of engagement data over arguments, and the top-left emphasis behavior. It does not explicitly state read-only behavior, what happens when both sources are empty, or any prerequisites like an active engagement, leaving notable gaps.

  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 and front-loaded: core function first, then data source, then purpose. It is bilingual, which doubles length, but both language versions earn their place. No redundant filler; the visual-emphasis sentence adds useful intent. Slightly long due to translation, but not bloated.

  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?

  The description covers the return value (table + Mermaid chart), the data source precedence, and the tool's visual goal. It lacks an explicit statement about the empty-input edge case (no engagement risks and no risks argument) and does not mention dependency on a current engagement context. Given the simple schema and absence of an output schema, this is a minor but real gap.

  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 input schema already documents both 'lang' and 'risks' thoroughly. The description reinforces the fallback role of the risks parameter ('無ければ引数から描く') but adds no meaning beyond what the schema descriptions already convey. Baseline 3 is appropriate.

  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 states a specific verb ('返す/Show'), a precise resource ('リスク/risks'), and the exact output format ('level × status matrix table and Mermaid quadrant chart'). It also clarifies the input source ('engagement or arguments') and the intended visual emphasis (top-left critical/untouched). This clearly differentiates it from related siblings like risk_matrix and diagram_stakeholder_matrix.

  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 the data-source selection rule: use engagement-registered risks if available, otherwise fall back to the risks argument. However, it does not provide explicit guidance on when to choose this tool over siblings like risk_matrix, nor any exclusions or alternative routing. Usage is implied rather than explicitly stated.

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

• get_roadmapA
  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 does disclose useful behavior: output is Markdown, content structure is specified, and non-YYYY-Qn timings sort last. However, it does not explicitly confirm the operation is read-only or describe behavior for edge cases like an empty or unset roadmap, which would strengthen 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 core purpose is front-loaded and the sorting behavior is a concise, valuable addition. The bilingual duplication adds length but is not wasteful given the likely Japanese/English usage context; overall it remains compact and focused.

  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 read-only-style getter with only two optional parameters, the description covers the output format, content components, and ordering rule. There is no output schema, but the description provides enough return-shape detail. It would be more complete with an explicit note about what happens when no roadmap exists, but that is a minor gap.

  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%: both 'lang' and 'includeCancelled' have clear descriptions in the schema, so the tool description adds no additional parameter-level meaning. The baseline of 3 applies because the schema fully documents parameters and the description does not need to compensate.

  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 uses a specific verb and resource: 'Return the roadmap as Markdown' and names the exact content components (quarter timeline, work packages by transition state, dependencies, benefits per step). This clearly distinguishes it from visual siblings like diagram_roadmap_gantt and mutation siblings like remove_roadmap_item.

  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 makes the tool's intended use clear by enumerating what it returns, so an agent can infer it is for getting a textual/Markdown roadmap overview. However, it never explicitly states when to prefer this over alternatives such as diagram_roadmap_gantt, nor does it mention any exclusions or when-not-to-use conditions.

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

• list_engagementsA
  3.7/5.0
  Behavior3/5

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

  With no annotations present, the description carries the full behavioral burden. It discloses two useful behaviors: the arrow marking the current engagement and the default hiding of archived engagements unless includeArchived is true. It does not mention read-only guarantees, return format, ordering, or pagination, though the list operation implies no mutation.

  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 compact and front-loaded with the main action, and each sentence adds a distinct detail. The bilingual duplication is slightly redundant but not wasteful.

  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 two-optional-parameter list tool, the description covers its core behavior and key default. The absence of an output schema and annotations is partially mitigated by the clarity of the list operation, though a note that the tool is non-mutating would make it 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 coverage is 100%, so the schema fully documents lang and includeArchived. The description adds a behavioral nuance for includeArchived (hidden unless true) that is not explicit in the schema description, but it offers no additional meaning for the lang parameter. Baseline 3 is appropriate.

  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 starts with "List the stored engagements," a specific verb and resource, and adds a distinguishing behavior: the current engagement is marked with an arrow. This clearly separates it from sibling tools like get_engagement, switch_engagement, or archive_engagement.

  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 its use when an agent needs to enumerate stored engagements and clarifies the includeArchived default. However, it does not explicitly state when to prefer this over similar siblings such as review_all_engagements or get_engagement, leaving the selection logic mostly to the tool name.

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

• read_documentA
  3.7/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 transparency burden. It discloses format-specific normalization behavior and the fallback for unsupported formats, and the verb 'read' implies a non-destructive operation. It does not discuss authorization or error handling, but these are secondary for a simple read tool.

  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 compact and front-loads the core action and supported formats, then adds normalization specifics. The bilingual duplication doubles length but is organized and not padded; it earns its place for a multilingual tool.

  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?

  Although there is no output schema, the description explains what the returned text looks like for each format and notes the unsupported-format workaround. It omits details about the workaround's shape and error behavior, but for a local-file reader the key decision factors are covered.

  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 lang, path, and maxChars. The description adds no parameter-level guidance beyond signaling supported file formats, which is already evident from the example extensions in the text; baseline 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 states a clear verb and resource: it reads a local document and returns normalized text, with concrete format mappings (CSV/TSV to Markdown, HTML/XML tag-stripped, JSON pretty-printed/outlined). It does not explicitly differentiate itself from sibling tools such as extract_from_document or ingest_document, so an agent must infer the distinction.

  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 when to use the tool: for local text-based files in the listed formats, and it explicitly warns that PDF/docx/xlsx are unsupported and produce a workaround. It provides no explicit when-not or alternative tool names, leaving the choice among document-processing siblings to inference.

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

• stakeholder_matrixA
  3.7/5.0
  Behavior5/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, and it delivers: it explains the quadrant placement, the per-quadrant guidance, the missing-field flagging, the specific conflict categories, the consequence and arbitrer/timing outputs, the source-column legend, the 'N/M 件' counting, and the fallback manual-review guidance. This is unusually complete behavioral 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 long and bilingual, which adds bulk, but nearly every clause conveys a distinct behavioral fact (conflict types, evidence, fallback, source counting, legend). It is structured and information-dense, though it could be tightened without losing meaning.

  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 high complexity, absence of an output schema, and absence of annotations, the description is remarkably complete. It covers outputs, edge cases (no conflicts detected), manual review suggestions, source traceability, and aggregation. An agent has enough context to call the tool and interpret its result 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?

  The only parameter, 'lang', has 100% schema description coverage with its enum and bilingual description, so the description does not need to add parameter meaning. The tool description adds no extra parameter semantics, matching the baseline for full 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 specifies the resource (stakeholders), the method (influence x interest quadrants), and the concrete deliverables (recommended engagement approach, flagged missing fields, conflict analysis, source counts). It does not explicitly differentiate itself from the 'diagram_stakeholder_matrix' sibling, though the analytical detail in the description makes the distinction inferable.

  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?

  There is no explicit guidance on when to use this tool versus alternatives such as 'diagram_stakeholder_matrix' or other analysis tools. The usage context is implied by the output description, but no when-to-use, when-not-to-use, or alternative-selection conditions are stated.

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

• analyze_text_with_claudeA
  3.8/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 prominently discloses the most critical trait: external outbound communication to the Claude API when an API key is configured, and no call otherwise. It also reveals the conditional output behavior (ready-to-paste prompt vs. structured JSON). It could add details about data handling or failures, but the core side effects are clearly exposed.

  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 short bilingual paragraphs with the critical external-communication warning bolded and front-loaded. Every clause contributes either behavioral context or configuration guidance, with no filler.

  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 4-parameter tool with no output schema, the description covers the main call conditions, the structured output mode, and the no-key fallback. It does not specify the exact response shape, but the `kind` enum and schema descriptions compensate for much of that. The behavior description is complete enough for an agent to invoke the tool and interpret the two possible 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?

  Schema description coverage is 100%, so the baseline is 3; the description adds a little by tying `kind` to structured JSON extraction with risks/stakeholders/requirements/summary cases. It does not expand meaningfully on `text` or `task` beyond what the schema already provides. Since the schema documents every parameter, this is adequate.

  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 names a specific verb (analyze) and resource (existing documents such as minutes/RFP/design docs), and clearly states the behavior of sending text to the Claude API or returning a prompt. It also identifies structured extraction via the `kind` parameter. It does not explicitly contrast with sibling document tools, but 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 Guidelines3/5

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

  The description gives concrete conditions: with an API key the text is sent outbound, without one it only returns a ready-to-use prompt, and `kind` requests structured JSON. This helps an agent understand when the tool has external side effects. However, it does not name alternatives like summarize_document_for_architecture, extract_from_document, or read_document, nor explain when to choose this tool over them.

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

• diagram_capability_mapA
  3.8/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 and discloses more than the bare operation: it returns a Mermaid diagram (not an image), uses three distinct encoding dimensions, and explains that fill and outline are independent axes so provenance of the heat judgment survives in the output. It stops short of covering edge behavior (orphan nodes, missing parents, defaults for omitted heat/confidence) but is strong for a rendering tool.

  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?

  Two dense sentences, front-loaded with the core function and encoding, then a short rationale for the two-axis design. The bilingual duplication (Japanese and English) roughly doubles the length, but this mirrors the tool's ja/en/both language support and every sentence carries substantive information about behavior.

  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 input side is well covered: all 3 parameters and all 6 nested fields are documented in the schema, and the description explains how inputs map to visual output. The main gap is the return value: the description says 'returns as a Mermaid diagram' but never states whether the agent receives Mermaid source text, which is the likely intended meaning, and there is no output schema to resolve the ambiguity. Edge-case behavior for inconsistent hierarchy data is also unaddressed.

  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%, so the baseline is 3 and the schema already explains each parameter, including confidence's role as an outline style on an axis independent of the fill. The description adds some value beyond the schema by specifying the concrete encodings (solid/dashed/dotted lines, ● △ × marks) and the low/medium/high fill mapping, but the marginal gain over the schema is modest.

  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?

  Uses a specific verb-resource pair ('Draw a business capability map as a nested Mermaid diagram') and specifies the exact visual encoding: subgraphs for hierarchy, fill for heat, outline style plus marks for confidence. The output format and encoding scheme make it immediately distinguishable from sibling diagram tools (diagram_value_stream, diagram_adm_cycle) and from content tools like draft_capability_map.

  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 makes the usage context inferable: when a capability map is needed as a visual Mermaid diagram with heat and confidence axes, this is the tool. However, it never explicitly names alternatives such as draft_capability_map or check_capability_map, nor states when NOT to use it, so routing must be inferred from the diagram_* sibling names rather than from the description.

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

• diagram_roadmap_ganttA
  3.8/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 disclosure burden and does it well: it discloses the output format (Mermaid Gantt), the data sources, the transformation logic (YYYY-Qn quarters converted to dates, transitions placed as milestones), and the diagnostic behavior (flags undated items and dependency conflicts). It stops short of stating whether the call is read-only or how the flags are surfaced in the returned chart.

  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?

  Two dense sentences front-load the core purpose before the diagnostic behavior, with no filler words. The bilingual ja/en duplication roughly doubles the length, but that is justified for a tool whose own lang parameter serves both audiences, and each clause earns its place.

  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 tool with no output schema and no annotations, the description explains the main return value (Mermaid Gantt chart) and data sources, but leaves questions open: how undated-item and dependency-conflict flags are reported in the output, what happens when neither engagement data nor items are available, and what 'dependency conflicts' means given the schema's items have no dependency field. Moderate complexity warrants a bit more disclosure.

  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 four parameters and every sub-property of items. The description adds modest context — that items serve as a fallback when no engagement data exists and that the quarter notation feeds the conversion logic — but per the baseline rule, the schema carries the heavy lifting.

  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 a specific verb and resource — 'Render the migration roadmap as a Mermaid Gantt chart' — which immediately distinguishes it from sibling data-retrieval tools like get_roadmap and from other diagram_* tools with different subjects (diagram_capability_map, diagram_adm_cycle). It further names the input sources (engagement work packages, transition architectures), making the tool's scope 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?

  The rendering purpose and the quarter-to-date conversion behavior imply a visualization use case, but the description never explicitly states when to choose this tool over get_roadmap (structured roadmap data) or the roadmap-editing siblings (prioritize_work_packages, remove_roadmap_item), nor does it give exclusions. Usage context is inferable from the purpose but not directly stated.

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

• generate_review_checklistA
  3.8/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 behavioral burden. It discloses the output format (Markdown checkboxes), the one-page length constraint, the 'send it back if missing' rule style, the four-level rating scheme, and the knowledge-base source of content. It does not explicitly state side effects, but the generation-focused language reasonably implies a non-mutating operation.

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

  Conciseness3/5

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

  The English portion is concise and front-loaded with purpose and output specifics. However, the Japanese version nearly duplicates the same information, adding length without adding distinct value for an AI agent evaluating the description, so not every sentence earns its place.

  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 there is no output schema, the description does well by explaining what the result looks like: a one-page Markdown checklist with four possible ratings and criteria derived from knowledge-base content. It covers the main behaviors an agent needs to understand to invoke and interpret the tool, though it could be slightly more explicit about returned content structure.

  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?

  Input schema coverage is 100%: every parameter has a description, with enum values and defaults documented for lang and scope. The tool description adds little parameter-specific meaning beyond restating the scope options, but because the schema is already fully descriptive, the baseline of 3 is appropriate.

  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 states a specific verb ('generate'), a specific resource ('architecture compliance review checklist'), and the exact scope options ('phase, deliverable, or implementation project'). It also specifies the output form ('Markdown checkboxes') and the review judgment scale, which clearly distinguishes it from siblings like generate_deliverable_template.

  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 for architecture compliance review checklists and names the three target scope types, so the intended context is clear. However, it does not explicitly say when to prefer this tool over similar siblings such as security_requirements_checklist or generate_deliverable_template, and it offers no exclusions.

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

• list_exportsA
  3.8/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 disclosure burden. It reveals meaningful behavior: newest-first ordering and the fields included in the listing. It does not discuss side effects or permissions, but 'list' strongly implies a read-only operation, and the disclosed behavior is adequate for this simple 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 two concise sentences, one in Japanese and one in English, with no filler. The essential facts—resource, returned fields, and ordering—are front-loaded, and every clause earns its place.

  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 two-parameter list tool with no output schema, the description adequately states what will be returned and in what order. Minor gaps remain around the exact response envelope and empty-list behavior, but these are not critical given the simple scope.

  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%, with clear descriptions for both lang and limit, including defaults and constraints. The description adds no parameter-specific meaning beyond what the schema already provides, so the baseline 3 applies.

  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 uses a specific verb+resource: 'List previously exported reports and deliverables.' It also names returned fields (path, size, mtime) and sort order (newest first). The phrase 'previously exported' helps distinguish it from export-related tools, though it does not explicitly name sibling alternatives.

  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 use case is implied clearly: list prior exports rather than create them. However, the description gives no explicit guidance on when to choose this tool over related tools like list_archimate_types, list_engagements, export_report, or export_deliverable, and it names no alternatives or exclusions.

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

• map_togaf_to_archimateA
  3.8/5.0
  Behavior4/5

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

  There are no annotations, so the description carries the burden. It makes clear this is a read-style lookup that 'returns' a structured set of content (including what not to draw), rather than mutating anything. It could add more about behavior for invalid phase IDs, but the output scope is well disclosed.

  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 (plus a necessary bilingual equivalent) carry the core scope up front and then list the additional return categories. There is no filler or repetition.

  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?

  With no output schema, the description compensates by enumerating the return categories (view name, layer, elements, deliverables, non-goals, weekly move). It doesn't give the exact output structure, but for this simple 2-parameter lookup tool the coverage is largely 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 schema already documents phase and lang with an example and enum. The description reinforces 'one ADM phase' but adds no parameter-specific detail beyond the schema, which is the expected baseline.

  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 names a specific operation — mapping one ADM phase to ArchiMate drawing guidance — and enumerates the exact output categories: layer, elements, view name, deliverables, exclusions. This specificity distinguishes it from sibling tools like archimate_vs_togaf or suggest_archimate_view even without naming them.

  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?

  It implies the use case ('for one ADM phase') but gives no explicit when-to-use instructions and no alternatives or exclusions. With dozens of sibling tools, the agent gets no routing help to choose this over suggest_archimate_view, generate_deliverable_template, or map_security_to_adm.

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

• mark_intake_doneA
  3.8/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, and it delivers: it discloses persistent data mutation ('saved data is updated'), a visible user-facing side effect (the Start screen changes so users can confirm items are cleared), and a reversal path (status='pending' puts an item back). Minor gaps are permissions and error conditions, but for a state-transition tool this is strong 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?

  Two short sentences per language, each carrying distinct information: purpose, mode selection, screen side effect, and reversal. The Japanese/English duplication doubles length but serves the tool's bilingual user base and lang parameter; no sentence is filler.

  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 5-parameter state-transition tool with no annotations and no output schema, the description covers the essential contract: what to target, that data is mutated, that the Start screen reflects the change, and how to reverse. Main omissions are the output the caller receives (despite the lang parameter implying some response) and behavior when ids and all=true are passed together, but the schema's 100% parameter coverage reduces the burden.

  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 already documents all 5 parameters (100% coverage), so baseline is 3. The description adds genuine value beyond the schema by clarifying that ids and all=true are alternative selection modes, and by explaining that status='pending' triggers a reversal rather than merely setting a different state. This relational meaning is not captured in the individual parameter descriptions.

  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?

  States a specific verb and resource: flips handed-over intake items to 'done' in the saved data, with explicit scoping modes (ids for specific items, all=true for all pending). It is unmistakably a state-transition/write tool rather than a read tool. However, it never names siblings like check_intake, so differentiation from related intake tools is implied rather than explicit.

  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?

  Explains the two target-selection modes (ids vs all=true) and the reversal via status='pending', which is solid within-tool usage guidance. But it never addresses when to choose this tool over alternatives (e.g., check_intake for viewing items, update_engagement for engagement edits), so cross-tool routing is left to inference.

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

• whats_new_for_meA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full disclosure burden. It does disclose genuine behavioral context: the two-list output structure and the emphasis that the stalled-items list is the primary value. But it never defines what 'もの' refers to (which entity type is listed), whether results are scoped to the active engagement, or how completed items are treated — meaningful gaps given annotations are absent.

  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?

  Two front-loaded sentences per language: behavior first, then purpose emphasis. The bilingual duplication is justified by the ja/en/both output parameter, and the second sentence earns its place by explaining why the tool exists. Slightly longer than strictly necessary due to the bilingual format, but nothing is wasted.

  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 tool (2 optional params, full schema coverage, no output schema), the behavior and parameter semantics are well covered. The main gap is the referent of 'もの' — an agent cannot determine what items appear in the lists (work packages, deliverables, findings?) or whether the query is scoped to the current engagement. A brief note on the entity type and scope would complete the picture.

  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%, so the baseline is 3. The description adds real value by clarifying that sinceDays plays a dual role: it defines both the 'recent' window for the first list and the stall threshold for the second ('未完了のまま N 日以上動いていない' / 'sitting unfinished for longer than that') — a relationship the schema's per-parameter description does not make explicit.

  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 uses a specific verb ('返す / List') tied to a concrete resource: items that moved in the last N days and unfinished items stalled N+ days. It goes beyond a bare statement by declaring that the second list is the point ('主目的は後者 — 止まっているものの発見'), giving the tool a distinct identity that separates it from status or dashboard siblings.

  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 through '進捗報告で最も価値がある情報がここにある' (the most useful thing in any status report is here), which signals a status-report scenario. However, no sibling alternatives are named and no 'when not to use' exclusions are given, so an agent must infer when to choose this over next_best_action, get_dashboard, or check_engagement_health.

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

• assess_maturityA
  3.9/5.0
  Behavior5/5

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

  Annotations are absent, so the description carries the full burden, and it succeeds: it discloses the return structure, the null-factor exclusion and M-of-N reporting, the default factor set, and the side-effect boundary that nothing is stored unless save=true. It even reveals that recommendations vary by score band, gap width, and note rather than factor name alone, which is valuable non-obvious 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 information-dense and front-loads the principal output before edge cases. Every sentence conveys a distinct behavior. The full Japanese/English duplication roughly doubles length, but it appears intentional given the tool's lang parameter and is not wasted text.

  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?

  With no output schema, the description must explain return values, and it does: bar table, overall score, per-factor reading, undetermined-factor report, and M-of-N verdict. It covers the complex edge cases well, though it leaves the exact output data shape and error behavior unspecified.

  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 every parameter. The description reinforces the critical current=null vs 0 distinction and the save=false default, but adds little new per-parameter meaning beyond what the schema states.

  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 opens with a specific verb and resource: 'Assess EA practice maturity' factor by factor, and enumerates concrete deliverables (bar table, overall score, per-factor reading, next move). It is clearly not a tautology. However, it never explicitly distinguishes itself from the sibling assess_readiness, leaving differentiation to the name alone.

  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 is rich in operational guidance: how to pass null, when not to persist (save=true), and what happens when factors are omitted. But it does not state when to choose this tool over alternatives such as assess_readiness or gap_analysis, nor when not to use it.

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

• check_capability_mapA
  3.9/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. It discloses that detection is mechanical, enumerates the exact anti-pattern categories, and states that each is returned with a concrete fix. It does not discuss limitations, output shape, or how hierarchy is supplied, but the core behavioral contract is clear.

  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 front-loaded with the core function and then enumerates the anti-patterns in a compact list. Though it is bilingual, both versions carry the same dense information without fluff. Every sentence earns its place.

  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 has no output schema, so the description should clarify return values; it only says each anti-pattern comes with a concrete fix, not the response structure. It also leaves ambiguity about how depth-related anti-patterns (4+ levels) are detected from a flat list of capability names, which is relevant for correct invocation.

  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 does not add parameter-level meaning beyond the schema; it elaborates on the analysis categories rather than on the capabilities or lang parameters. The 'one level at a time' guidance lives only in the schema, not in the description.

  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 that it takes a list of capability names and mechanically detects eight named anti-patterns, returning a concrete fix for each. It is specific about the resource and operation, but it does not explicitly differentiate itself from the closely related sibling business_architecture_antipatterns, leaving some potential for confusion.

  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 usage context: when you have capability names to check for anti-patterns. The input schema adds a useful guideline ('pass one level at a time for best results'), but the description itself does not state when to prefer this tool over alternatives or when not to use it, so exclusions are missing.

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

• check_engagement_healthA
  3.9/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the full burden and largely succeeds: it discloses the output contract (severity-tagged flags, concrete recommendations, named inferred/untraceable entries, counting behavior) and a notably nuanced rule — positives are only reported when at least one entry can actually be pointed at in the original, guarding against fabricated 'good news'. The verb set (report, count, name, return) strongly implies a read-only operation, though it never explicitly states that engagement data is unchanged.

  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 English text is dense and well front-loaded: the first sentence states the core purpose and deliverables, the second adds traceability counting and naming, the third the nuanced positives rule — every clause earns its place. The full Japanese duplicate roughly doubles length, but this appears intentional given the tool exposes a lang parameter (ja/en/both) and serves a bilingual audience.

  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?

  With no output schema and no annotations, the description carries the completeness burden and compensates well: it specifies exactly what the tool returns — severity-tagged red flags with recommendations, traceability counts, named inferred entries, and a guarded positives section. The exact output rendering (e.g., structured list vs. prose report) is unstated, and 'current engagement' relies on a system-level concept established by siblings, but the behavioral contract is clear enough for an agent to invoke and interpret results 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 description coverage is 100% — both asOf (date pattern, default 'today') and lang (enum with default 'both') are fully documented in the schema. The description adds no parameter-level detail, but the baseline of 3 applies because the schema already carries the full burden; no compensation is needed.

  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?

  States a specific verb and resource — 'Audit the current engagement' — and enumerates concrete deliverables: red flags (missing sponsor, unowned high risks, overdue actions, unapproved key deliverables, empty registers) with severity and recommendations, plus source-traceability counts and a guarded positives section. The specificity makes the purpose unmistakable and effectively differentiates it from siblings like check_intake, inspect_findings, or review_all_engagements, even without naming 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 conveys clear context — run this to audit the currently active engagement for practical red flags — and the 'current engagement' framing signals its scope. However, it never states when not to use it or names an alternative for overlapping concerns (e.g., inspect_findings for findings-level review, check_intake for intake status). Usage is implied by the tool's name and audit framing rather than explicitly routed.

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

• compare_with_togafA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description must carry behavioral disclosure; it does state that the tool returns a table, which implies a read-only query, and it enumerates the table contents. It does not address failure behavior, unknown framework IDs, or data sources, so coverage is decent but not complete.

  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 Japanese sentence and one English sentence deliver the same complete information with no filler, and the output dimensions are listed compactly. It is front-loaded and every word earns its place, including the bilingual pairing.

  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 two-parameter tool with comprehensive schema descriptions and no output schema, the description fully specifies what the agent should expect: a table with five named dimensions. No critical information is missing for selecting or invoking the 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 coverage is 100%, so the schema already documents framework and lang. The description adds no parameter-level detail beyond saying 'named framework', which matches schema. Baseline 3 applies.

  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 uses a specific verb ('返す' / 'returns') and names the exact resource: a side-by-side table of TOGAF versus the named framework, with five concrete viewpoints. This differentiates it from siblings like archimate_vs_togaf and recommend_frameworks by making the comparison object and output explicit.

  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: call when you need a structured TOGAF comparison for an arbitrary framework. However, it never states when not to use it or points to alternatives such as recommend_frameworks or archimate_vs_togaf, leaving the choice to inference.

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

• diagram_c4_contextA
  3.9/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 burden of disclosing behavior. It does state that the tool returns a Mermaid diagram and describes what it includes. However, it does not mention side effects, failure modes, or whether an empty users/externalSystems list changes the output, though for a generation tool this is a moderate gap rather than a severe one.

  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 concise and front-loaded: the first sentence states exactly what the tool does, followed by supporting context. The bilingual repetition is justified by the tool's language-aware nature and is not excessive. Overall, every sentence contributes functional or selection-relevant information.

  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 diagram generation tool with no output schema, the description reasonably covers the output format (Mermaid), the diagram level (C4 context/level 1), and the supported element types. It could say more about defaults for empty arrays or how labels are generated, but the provided context is sufficient for correct invocation in most cases.

  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 each parameter. The description adds conceptual meaning by explaining the intended diagram roles (people, system, external systems, short relationship labels), which maps to users, system, externalSystems, and relation, but it does not significantly extend the parameter-level semantics.

  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 (draw/return) and resource (C4 system context diagram, level 1, in Mermaid), and further specifies the diagram elements: people, system in scope, external systems, and relationship labels. This distinguishes it from the other diagram_* siblings like diagram_adm_cycle or diagram_value_stream because it names the C4 level 1 notation explicitly.

  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 clear usage context: C4 is lightweight and suited when an executive must understand the system in thirty seconds. It does not explicitly name alternatives or state when not to use this tool, but the scenario guidance is strong enough for an agent to choose it appropriately among many diagram tools.

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

• estimate_tokensA
  3.9/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the full burden. It clearly discloses the most consequential behavior: with an API key the text is transmitted to an external Claude endpoint, and without one it uses a local approximation. This is a significant privacy and side-effect disclosure that goes well beyond the schema. It does not cover error cases or latency, but the key behavioral trait is transparently stated.

  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 definition is compact — two bilingual sentences that state purpose and a critical behavioral caveat. The bilingual repetition doubles length but every core fact earns its place; nothing is fluff. The most important caveat (outbound call) is bolded and placed early.

  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 two-parameter tool with no output schema, the description explains the main behavior and the fallback. It does not explicitly state the return value, but 'estimate a text's token count' reasonably implies a numeric result. Overall, an agent has enough to decide whether and how to invoke it.

  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 repeats the purpose but adds no parameter-level detail beyond the schema's own text and lang descriptions. No compensation is needed because the schema already documents both parameters.

  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 a specific verb and resource: 'estimate a text's token count.' It further differentiates the tool by detailing two execution modes — calling the Claude count_tokens endpoint or falling back to a character-based approximation — making its function unambiguous even without comparing sibling tools.

  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 for estimating token counts but gives no explicit guidance on when to prefer it over alternatives, nor when not to use it. No sibling or alternative is mentioned. The conditional API-key behavior is a usage-relevant detail but does not substitute for explicit routing guidance.

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

• export_archimate_open_exchangeA
  3.9/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 disclosure burden. It does state the core side effect — writes a file to disk — which is the most safety-relevant behavior for an export tool, and names the XML standard. However, it leaves implicit whether the export mutates the model (it reads as non-destructive but never says so) and does not describe overwrite/conflict behavior beyond the schema parameter. 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.

  Conciseness4/5

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

  Both language blocks open with the core purpose, then the format, then the interoperability value, then the sibling pointer — every sentence earns its place and the key facts are front-loaded. Bilingual duplication doubles the length, but it is symmetric and a deliberate pattern for this tool family, costing one point.

  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 tool with 9 optional parameters, a 100%-covered schema, and no output schema, the definition is reasonbly complete: purpose, output format, destination, and input parity with a sibling are all stated. The main gaps — what a successful call returns (file path?) and explicit alternative-routing — are not cripling because the schema covers parameters and the description covers the tool's nature.

  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 bilingual per-parameter descriptions (including the relations/relationships aliasing and the 'no line is drawn without relations' caveat), so the schema does the heavy lifting and the baseline 3 applies. The description adds one genuinely useful cross-reference — 'Same inputs as export_archimate_csv' — which lets agents transfer knowledge from the sibling, but it contributes no per-parameter detail.

  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 names a specific verb and resource ('Write an ArchiMate model to disk'), pins the exact format (Open Exchange File / XML), and adds the interoperability value proposition ('the interchange format other ArchiMate tools read'). This clearly differentiates it from the CSV sibling by format and consumption context.

  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 'the interchange format other ArchiMate tools read' gives clear context for when this tool is the right choice, and 'Same inputs as export_archimate_csv' links the closest sibling, telling agents their existing input knowledge transfers. It stops short of an explicit when-to-use versus when-not-to-use statement (e.g., 'use export_archimate_csv for tabular/ spreadsheet consumption'), so it does not reach a 5.

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

• next_best_actionA
  3.9/5.0
  Behavior4/5

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

  With no annotations, the description carries the transparency burden, and it does well: it discloses that the tool analyzes stored engagement state, returns 3-5 actions, includes evidence/completion conditions/tool recommendations, and is prescriptive ('do this this week') rather than theoretical. It does not explicitly state read-only behavior, but 'diagnose and return' implies no mutation.

  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 bilingual description is compact and front-loaded: the first clause states the core function, followed by output details and a clarifying intent phrase. The 'not chapter 7 but this week' sentence is illustrative rather than redundant, though the Japanese/English duplication occupies extra space.

  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 an output schema, the description sufficiently characterizes the return value (3-5 prioritized actions with reason, completion condition, and tool). It also signals the prerequisite that an engagement must already be stored/saved. It could be more explicit about error conditions or behavior when no stored engagement exists, but is otherwise 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% and both parameters are self-described enums with defaults (lang, horizon). The description adds no additional parameter guidance, which is acceptable because the schema already handles parameter semantics.

  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 states a specific action: diagnose the stored engagement across named dimensions and return 3-5 concrete, prioritized actions with reason, completion condition, and tool. This is far more specific than a generic 'next best action' label and clearly distinguishes it from sibling planning/diagnostic tools.

  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 phrasing '今週これをやれ' implies it is for users who want actionable next steps rather than generic guidance, but it never explicitly states when to choose this over siblings like prioritize_work_packages, assess_readiness, or check_engagement_health. No exclusions or alternative routing are provided.

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

• review_security_postureA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It does disclose the core operation ('Read ... and report') which implies non-mutating behavior, and it enumerates exactly what it inspects. However, it does not explicitly state that the tool makes no modifications to the engagement, describe the output format of the report, or mention edge-case behavior such as when no engagement is active.

  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 English sentence is front-loaded with the core action ('Read the current engagement and report security gaps') followed by a compact, colon-delimited list of detection categories that earns its place by telling the agent what counts as a gap. The bilingual duplication doubles length but is justified for the JA/EN audience; still, it prevents a 5 for conciseness.

  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 low-complexity tool (one optional enum parameter, no output schema, no annotations), the description covers the essential context: the operation, the target (current engagement), and a detailed taxonomy of what it detects. Minor gaps remain — the return value shape of the 'report' and behavior when no engagement is active are not described — but nothing critical is missing for correct invocation.

  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% — the single optional `lang` parameter is fully documented in the schema with an enum, default, and bilingual description. The tool description adds nothing about parameters, so the baseline score of 3 applies; the description correctly refrains from duplicating what the schema already covers.

  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 states a specific verb+resource ('Read the current engagement and report security gaps') and enumerates six concrete gap categories (missing security stakeholder, ownerless severe risks, accepted risk without acceptor, missing deliverables, missing regulatory deadlines, missing disposal dates). This specificity clearly distinguishes it from siblings like review_all_engagements (all engagements vs. current), check_engagement_health (general health vs. security-specific), and gap_analysis (general gaps).

  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 clear context by scoping the tool to the current engagement and to security-specific concerns, which implicitly routes the agent away from review_all_engagements, gap_analysis, and check_engagement_health. However, it never names an alternative or states a when-not-to-use condition explicitly, so the exclusion logic is left to inference.

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

• explain_forA
  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 of behavioral disclosure. It explicitly states that it reads stored engagement data, translates signals from the topic for different audiences, and that the jargon table lists only terms appearing in the topic. This goes well beyond the schema. It does not mention potential side effects, but the read-and-build wording makes mutation unlikely.

  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 front-loaded with the core action and organized into clear behaviors. It is longer than necessary because it repeats the same content in Japanese and English, but each clause carries substantive information about the tool's behavior, audience parsing, and output constraints. The duplication is a minor inefficiency, not padding.

  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?

  There is no output schema and no annotations, so the description must explain the return value. It says it builds and returns a pitch and mentions the jargon table, but it does not describe the output structure, how the lang parameter affects the output, or the dependency on an existing engagement being active. Some key operational context is missing for a tool with this complexity.

  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 description coverage is 100%, so the baseline is 3. The tool description adds value beyond the schema by explaining how the audience parameter is interpreted (seniority and functional patch are read from free text) and how the topic parameter's signals (money, dates, past failures, risk) are used to shape the output. This helps the agent craft better parameter values.

  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 states a specific action ('Build the pitch from what you wrote in topic plus the stored engagement') and resource ('stored engagement (readiness, risks, stakeholders, work packages, dates)'). It clearly distinguishes the tool by its audience-translation behavior, which is unique among the sibling list. The verb is specific and the scope is well-defined.

  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 for constructing an audience-specific pitch from a written topic and stored engagement data, but it does not explicitly state when to use it versus alternatives or name any sibling tools. It gives no exclusion criteria or decision guidance, so the agent must infer usage from the described behavior.

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

• llm_statusA
  4/5.0
  Behavior4/5

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

  No annotations exist, so the description carries the behavioral burden. It explicitly discloses a key security behavior: the key value is never shown, only its presence. It also states the content (model and setup method). It does not mention side effects, but this is a read-only status tool, and the disclosed behavior is the most important one.

  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 short sentences with no filler. It front-loads the primary purpose and immediately adds the critical privacy guarantee. The bilingual formatting is compact and each part earns its place.

  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 status-check tool with one optional parameter and no output schema, the description provides enough detail: it lists the key informational fields (key presence, model, configuration method) and the privacy constraint. It could mention the exact return format, but that is a minor gap given the low complexity.

  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%: the single parameter 'lang' is fully documented in the schema with enum values, default, and bilingual description. The tool description adds no extra meaning about the parameter, so the baseline of 3 applies.

  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 states a clear verb ('report') and resource ('optional Claude API path'), and specifies exactly what it covers: key presence (never value), model, and configuration method. This differentiates it from sibling tools like analyze_text_with_claude or estimate_tokens, which assume the API is available.

  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 clearly implies when to use the tool (to check whether Claude API integration is available/configured) but does not explicitly name alternatives or exclusion conditions. Given the large sibling set, explicit routing hints would strengthen it, though the purpose is self-evident for a status check.

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

• map_security_to_admA
  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 behavioral burden; it does so by stating that the tool 'returns' a specific set of security guidance without implying mutations. The mention of questions that must be answered before leaving the phase adds useful behavioral context, though it does not describe output format or data source.

  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 bilingual description is compact and front-loaded: it names the resource, the context, and all four output categories in two sentences. There is no filler or repetition beyond the intentional bilingual mirror.

  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 read-only advisory tool with only two parameters and no output schema, the description gives enough information to select and invoke it: the phase is clear, the output categories are enumerated, and the schema covers the remaining invocation details. It would benefit from examples or a note on how the output is structured, but these are not critical.

  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 already documents both parameters completely (100% coverage), so the description adds little beyond the schema. It reinforces that the phase is the central input, but it does not enrich the semantics of 'lang' or the accepted phase identifiers.

  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 uses a specific verb ('return') and resource ('security layers, questions, artifacts, and failures for a given ADM phase'), which clearly states what the tool does. It is clear enough to distinguish from general ADM tools, though it does not explicitly differentiate from sibling security tools such as threat_model_starter or security_requirements_checklist.

  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 a given ADM phase' and 'before leaving the phase' provide a clear context for when to use the tool: during ADM phase work when security alignment is needed. It does not mention when not to use it or name alternatives, so it stops short of a 5.

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

• value_stream_methodA
  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 behavioral burden. It clearly discloses that the tool returns a 7-step method, that each step includes an output and failure mode, and that passing `step` returns a single step. This makes the behavior predictable and reveals the key parameter-driven behavior, though it doesn't discuss side effects or state changes, which is appropriate for a pure information-returning 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 appropriately sized and front-loaded: it states the core purpose, the approach, what each step contains, and the optional `step` parameter in a compact bilingual format. Every clause earns its place, and the bilingual repetition is purposeful given the language toggle.

  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 low-complexity tool with two optional parameters and no output schema, the description is nearly complete. It covers the number of steps, the working-backwards approach, the content of each step, and the single-step option. It does not specify the output's formatting or structure, but that level of detail is not essential for a method-returning 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's mention of the `step` parameter ('Pass `step` for a single step') adds no new meaning beyond the schema's 'Return a single step (1–7)'. The `lang` parameter is also already fully described in the schema, so the description adds no additional parameter semantics.

  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 states a specific verb and resource: it returns a seven-step method for building a value stream, working backwards from receiver and end state. It distinguishes itself from sibling tools like diagram_value_stream, which produce diagrams rather than steps, and capability_method, which targets capabilities. The bilingual phrasing reinforces the intended purpose.

  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 usage context is implied: it is the tool to call when you need the step-by-step method for building a value stream. However, it does not explicitly state when to use it versus related tools, nor does it mention alternatives or exclusions. The guidance is present but left to inference.

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

• add_transition_stateA
  4.1/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 of behavioral disclosure. It does disclose an important behavior: warns when standalone viability or a disposal plan is missing. However, it omits other significant behaviors such as whether updates are partial or full replacements, what happens on validation failure, and what the response contains. This is adequate but leaves room for more 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 compact—two bilingual sentences—with the core action stated first. Every clause adds meaningful information: the resource, the add/update distinction, and the warning behavior. There is no redundant or filler content.

  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 12-parameter mutation tool with no output schema and no annotations, the description covers the core add/update semantics and one warning but leaves out important context: whether an active engagement is required, how updates affect unspecified fields, and what the tool returns. The complexity is high enough that these omissions make the description only partially complete.

  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 description coverage is 92%, so the baseline is 3. The description adds meaning beyond the schema by explaining the id parameter's dual role ('id を渡すと更新、省略で新規') and by calling out the two business-critical fields standalone and disposalPlan through the warning behavior. This pushes it above the baseline.

  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 states a specific verb and resource: 'Save a transition architecture (intermediate state) to the engagement.' It also distinguishes the two modes of the tool—'Pass an id to update, omit it to add'—so the agent understands exactly what action it performs. This clearly differentiates it from sibling tools like add_work_package or remove_roadmap_item.

  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 gives clear context for when to use the tool: when saving or updating a transition architecture for an engagement. It explicitly explains how to choose between add and update via presence of id. It does not name alternatives or exclusion criteria, but the tool's purpose is distinct enough among siblings that this is a minor gap.

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

• assess_readinessA
  4.1/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full behavioral burden, and it does so thoroughly. It discloses the non-destructive default, the save=true side-effect, the null-exclusion behavior, why 'no risk' is not confused with 'not looked at', risk-factor handling with update_engagement JSON, and per-factor source/confidence attribution. This is exemplary 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 front-loaded with purpose and outputs, then moves through risk handling, null semantics, attribution, and persistence. It is longer because it is bilingual, but both language versions earn their place by conveying dense behavioral rules efficiently. Only minor redundancy with schema descriptions prevents a 5.

  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 complexity, lack of output schema, and absence of annotations, the description covers the return values, the recommendation logic, the risk-JSON integration, the null semantics, the source/confidence options, and the save behavior. An agent can correctly invoke and interpret results from this description alone.

  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 description coverage is 100%, so the baseline is 3. The description adds genuine cross-parameter meaning beyond the schema: recommendations depend on score band, gap width, and note content, not just factor name, and null current values interact with verdict exclusion. This meaningfully exceeds what the schema alone provides.

  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 names a specific activity ('assess transformation readiness') and a concrete result set: bar table, overall verdict, per-factor reading with next move. It is clearly distinct from generic assessment tools, but it does not explicitly differentiate itself from the similarly named sibling 'assess_maturity' or from 'gap_analysis', so it falls just short of full sibling differentiation.

  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 gives strong operational guidance for calling the tool, such as passing null for undetermined factors and setting save=true to persist, but it never states when to choose this tool over alternatives like assess_maturity or gap_analysis. Usage is implied by the subject matter, not explicitly scoped with exclusions or sibling trade-offs.

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

• cross_mapA
  4.1/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 behavioral disclosure burden. It is transparent that the tool returns an empty template rather than a filled map, and it discloses the auxiliary content (legend, how to fill, how to interpret). No mutation or side effects are implied.

  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 compact sentence that front-loads the three use cases before listing output components. The bilingual duplication is justified by the lang parameter, and there is no filler or irrelevant context.

  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 there is no output schema, the description adequately covers what the agent will receive: an empty matrix, legend, fill instructions, and reading guidance. It does not explicitly state that rows and columns from the parameters populate the matrix, but the schema already defines those parameters, so the calling contract is sufficiently 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%, and the schema already documents the kind enum, rows, columns, and lang parameters. The description adds no additional parameter-level semantics, so the baseline score of 3 applies.

  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 names the exact output: an empty Markdown matrix, legend, fill instructions, and reading guidance. It also scopes the tool to three specific cross-mapping kinds, making it clearly distinct from sibling tools like diagram_capability_map or draft_capability_map.

  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 clearly states the usage context: capability × value stream, capability × organisation, or capability × application. It does not explicitly mention exclusions or alternative tools, but the conditions for use are clear enough for an agent to select this tool.

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

• diagram_stakeholder_matrixA
  4.1/5.0
  Behavior4/5

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

  With no annotations present, the description carries the full behavioral burden and delivers meaningful disclosure: the boundary rule (medium counts as the high side, boundary cases marked '*'), verbatim rendering of recorded approaches with generic placeholders only for unset ones, and the independence of the confidence axis from quadrant placement. The confidence-mark behavior is partially already in the schema, but the quadrant-edge rule and placeholder behavior are genuinely additive.

  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 bilingual structure doubles length, but every clause earns its place and information is front-loaded: purpose first, then quadrant rule, approach handling, and confidence axis. The two most decision-relevant facts (medium counts as high; inferred placements are visually marked) appear early. Slightly long due to ja/en duplication, but nothing is filler.

  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?

  With no output schema, the description appropriately discloses the output form (Mermaid quadrantChart) and the rendering rules that affect how results will look. The notable gap is empty-input behavior: stakeholders defaults to [] and the schema hints at engagement-data fallback, but the description never states what happens when no stakeholders are supplied, leaving a plausible misinvocation path for agents without engagement context.

  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 alone documents all parameters and object fields, including the ● △ × marks on confidence and the verbatim display of approach. The description adds only the quadrant boundary rule (how influence/interest map to positions), which is useful but is rendering behavior more than parameter semantics. At full schema coverage the baseline of 3 applies, and the description contributes modest extra meaning.

  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 names a specific verb (配置する/Plot), a specific resource (stakeholders), and an output format (Mermaid quadrantChart), stating the influence × interest 4-quadrant scope. It distinguishes itself from the sibling stakeholder_matrix by explicitly referencing the same quadrant rule while making clear this tool renders a diagram rather than the matrix judgment itself.

  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 clearly positions this as the visual-diagram counterpart to stakeholder_matrix ('quadrants are decided by exactly the same rule as stakeholder_matrix'), giving an agent enough context to prefer it when a chart is requested. However, it never explicitly states when NOT to use it or names alternative diagram tools (e.g., diagram_risk_matrix), leaving exclusion conditions implied rather than stated.

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

• get_dashboardA
  4.1/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 disclosure burden. It honestly explains that large tables are automatically trimmed to top rows and that the tool always indicates when trimming occurs. This is meaningful behavioral context beyond 'returns a dashboard', though it does not address edge cases like missing current engagement.

  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 compact and front-loaded, leading with the core action and format. The bilingual duplication is justifiable in context and does not bloat the entry, though it slightly reduces efficiency.

  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 low-complexity tool with three optional parameters and no output schema, the description adequately explains output format, intended audience, and the key trimming behavior. It does not mention behavior when no current engagement is active, but this is a minor gap given the overall clarity.

  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%, with each parameter already having a clear description including defaults and the compact behavior. The tool description adds little beyond the schema, so the baseline of 3 is appropriate.

  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 states a specific verb ('Return'), a resource ('the current engagement'), and a deliverable format ('Markdown dashboard'). It clearly distinguishes itself from siblings like get_engagement, open_dashboard, and export_report by framing the output as a chat-friendly, print-friendly status view.

  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 clear context: this is for displaying current engagement status in chat, copy-paste, or print scenarios. It does not explicitly name alternatives or state when not to use it, but the intended use case is clear enough for an agent to route appropriately.

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

• list_archimate_typesA
  4.1/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 and it does well by disclosing the type-matching normalization (case, spaces, hyphens are ignored) and that results are grouped by layer with usage notes. The read-only nature is implied by 'List'.

  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 concise and front-loaded with the main purpose, then adds the matching behavior. The bilingual duplication is somewhat redundant but justifiable for multilingual users; no irrelevant filler is present.

  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 listing tool with three optional parameters, full schema coverage, and no output schema, the description gives enough context: accepted types, grouping, practical notes, and matching semantics. Return format is not explicitly stated, but 'list ... grouped by layer' implies the shape adequately.

  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 fully documents the lang, group, and relationsOnly parameters. The description adds little beyond the 'grouped by layer' idea, which loosely maps to the group parameter, but it does not need to compensate since the schema is complete.

  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 lists element and relationship types accepted by export tools, grouped by layer with practical notes. This is a specific verb+resource and distinguishes it from sibling tools like export_archimate_csv or validate_archimate_relationship.

  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 gives clear context: use this tool when you need to know which ArchiMate element/relationship types can be passed to the export tools. It does not explicitly name alternatives or exclusion conditions, but the usage situation is obvious enough for a listing helper.

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

• prioritize_work_packagesA
  4.1/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 and does a good job: it discloses the classification mechanism, the quadrant count, and the fact that prerequisite-blocked items are flagged. The word '返す/return' signals a non-mutating reporting operation, though it could be more explicit about not persisting changes.

  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 two parallel one-sentence statements (Japanese and English) with no filler. It is slightly redundant across languages, but for a bilingual tool this is conventional and still compact.

  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 zero required parameters and no output schema, the description adequately explains what is returned (quadrant-classified work packages with blockage notes). It leaves the source of the work packages implicit, but the sibling tool set and engagement context make this recoverable.

  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% for both optional parameters (lang, includeDelivered), so the baseline of 3 applies. The description doesn't add parameter-level detail, but none is needed because the schema already documents both.

  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 names a specific verb ('Sort work packages') and a precise method (four quadrants of business value against effort), plus the distinct behavior of flagging blocked items. This clearly distinguishes it from roadmap retrieval/editing siblings.

  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 makes the intended use apparent: when work packages need a value-vs-effort prioritization view with blockage notes. It doesn't explicitly name alternatives or exclusions, but the operation is specific enough that selection is clear.

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

• remove_roadmap_itemA
  4.1/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 and delivers: it reveals that the default invocation is non-destructive ('nothing is deleted and only the impact is reported') and that deleting a transition state detaches its referenced work packages. This covers the critical safety and cascade behavior an agent needs before invoking a destructive tool; only reversibility and permission requirements are left unstated.

  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 two compact bilingual sentences ordered logically: core purpose first, then the default safety behavior, then the cascade consequence. There is no filler, and the bilingual duplication is justified by the lang parameter supporting ja/en/both, though it does roughly double the length.

  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 3-parameter tool with 100% schema documentation and no nested objects, the description covers what is deleted, the safety default, and the side effect on work packages — everything essential to invoke it correctly. Since no output schema exists, a sketch of the impact report's return shape would improve it, and an explicit routing note against delete_engagement is missing, but these are minor 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?

  Schema description coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it explains the confirm=false behavior from the reverse direction (impact-only return), clarifies that id targets either a transition state or a work package, and ties the deletion to the 'saved engagement' context. This enriches the schema's terse 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 opens with a specific verb and resource — 'Delete a transition state or work package from the saved engagement' — and explicitly names both deletable entity types. This distinguishes it from siblings like add_transition_state, add_work_package, get_roadmap, and the broader delete_engagement, so an agent can tell them apart without opening schemas.

  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 a safe usage workflow: run with the default confirm=false to get an impact report before actually deleting, and it notes the detach side effect. However, it never names alternatives or states when not to use this tool (e.g., no pointer to delete_engagement for whole-engagement removal), so usage context is clear but exclusions are absent.

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

• review_all_engagementsA
  4.1/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 behavioral burden. It discloses that the tool reads all stored engagements, sorts them by risk, computes progress, overdue/blocked actions, live high risks, staleness, and critical health findings, and returns a verdict with named items for stalled engagements. The read-only nature is strongly implied by 'review' and 'roll into one table,' and no mutation behavior is hinted at.

  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 front-loaded with the core function and then presents the output columns and verdict logic in a logical, structured way. It is slightly longer due to full bilingual duplication, but both the Japanese and English versions are parallel and fill the description with relevant information rather than generic filler.

  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?

  In the absence of an output schema, the description compensates well by specifying the table contents, the verdict categories, and the fact that stalled engagements include specific named items. All four parameters are documented in the schema with defaults and constraints. Edge cases and error behavior are not covered, but for a read-only review tool this is sufficient.

  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 every parameter already documented with defaults, types, and ranges. The description reinforces the concept of staleness and the worst-first ordering, but it does not add meaningful depth beyond what the schema already provides for asOf, lang, staleDays, or includeArchived.

  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 names a specific verb and resource ('roll every stored engagement into one table, worst first') and enumerates the exact per-engagement metrics it aggregates. It also positions itself as the only tool for cross-engagement review, clearly distinguishing it from single-engagement siblings like check_engagement_health or list_engagements.

  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 clearly signals the intended use case — reviewing multiple engagements at once, worst first — and explicitly claims to be the only tool for this purpose. It does not name sibling alternatives or state when not to use it, but the scope is unambiguous enough for an agent to route to it correctly.

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

• tailor_admA
  4.1/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, and it discloses the key behaviors: it returns a table (表で返す), specifies what the table contains, and states the central design premise that phases get cut rather than run in full. The '返す / return' phrasing implies a non-persisting design operation. It does not explicitly address side effects or edge cases like an undersized timebox, but the core behavior is transparent for a design-and-return tool.

  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 compact: the first sentence front-loads the action and the full output specification, and the second adds the philosophical premise. The bilingual Japanese/English duplication doubles the length, but this is justified by the lang parameter supporting ja, en, and both. Every part earns its place with no filler.

  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?

  Since there is no output schema, the description properly takes on the job of explaining the return value: a table containing phases to run/cut, deliverables, durations, and review placements. It covers the primary inputs (scale, purpose, timebox) and the design logic. Minor gaps remain — it does not address what happens when timeboxWeeks is absent or how hasExistingEa influences the result — but the schema covers those parameters, so the overall picture is complete enough.

  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 of 3 applies. The description echoes scale, purpose, and timebox as the three design inputs but adds no new parameter-level meaning beyond what the schema already documents — the cutting behavior is stated in both the timeboxWeeks schema description and the tool description. The lang and hasExistingEa parameters are omitted from the description but fully covered in 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 states a specific verb and resource — 'Design a tailored ADM from scale, purpose, and timebox' — and enumerates the concrete outputs: phases to run/cut with reasons, deliverables to produce/skip, durations per phase, and review placements. This clearly distinguishes it from siblings like compare_with_togaf, diagram_adm_cycle, and map_security_to_adm, which do comparison, diagramming, and security mapping respectively.

  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 a clear trigger context: use this when you have a scale, purpose, and timebox and want a custom, cut-down ADM plan rather than the full framework. The premise statement ('ADM is meant to be cut down, not run whole') further clarifies the intended use case. It does not explicitly name alternatives or when-not-to-use, but the positioning against comparison/diagramming siblings is reasonably clear.

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

• update_engagementA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the transparency burden and does meaningful work: it discloses partial-update semantics (unspecified entries are left alone), the upsert rule (id = update, omit = add), the provenance requirement (source and confidence on every entry), and a response contract (the response reports how many entries still have no source). It also documents the convention for confidence='inferred'. Minor gaps remain around error handling for nonexistent ids and authorization, but the core mutation behavior is well disclosed.

  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 front-loaded with the core action and scope, then flows logically through the upsert rule, provenance fields, response behavior, and the inferred-source convention. The bilingual format doubles length, but that matches the tool's ja/en/both lang parameter, and every clause earns its place.

  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 tool this complex — 15 parameters with seven nested object types, no annotations, and no output schema — the description covers the essential behavioral contract: partial update semantics, upsert pattern, provenance requirements, and the key response behavior. It doesn't document error cases, authorization, or whether supplied ids must already exist, but those are reasonable omissions against how much the description does convey.

  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 only 33%, so the description must compensate — and it does. Rather than enumerating each of the 15 parameters, it explains the cross-cutting semantics that apply to all array-entry types: supply an id to update, omit it to create; each entry can carry source and confidence; the confidence values are enumerated with their meaning; and the response reports the count of unsourced entries. This adds meaning the per-field schema descriptions cannot convey.

  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 states a specific verb and resource ('Partially update the engagement') and enumerates exactly what can be changed: phase statuses and add/update of risks, decisions, actions, stakeholders, deliverables, and notes. This clearly separates it from siblings such as create_engagement, get_engagement, archive_engagement, and delete_engagement.

  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 makes the tool's scope clear — any partial modification of an existing engagement — so the intended use is implied. However, it never explicitly names alternatives or states when not to use it (e.g., when to prefer create_engagement or delete_engagement), so routing to this tool is left to inference from the sibling names.

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

• validate_archimate_relationshipA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden and does disclose the verdict categories (ok/questionable/likely-wrong), that reasoning and alternatives are always returned, and the underlying judgment principle. It does not describe the exact response shape, but the core behavioral contract is visible.

  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 compact and front-loads the verdict categories and the key methodological caveat. The Japanese/English bilingual repetition doubles length, but it serves the tool's lang parameter and both outputs are equally succinct.

  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?

  The tool is simple, the schema covers all parameters, and the description explains the output classes, reasoning, alternatives, and decision logic. The absence of an output schema is partially mitigated by the description, though no exact response structure is given.

  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 parameters are already well documented. The description adds a general semantic purpose but no additional per-parameter detail beyond what the schema provides, which fits the baseline of 3.

  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 uses a specific verb—validate—and names the exact resource, an ArchiMate relationship, with a three-way verdict plus reasoning and alternatives. It also differentiates the tool from a generic permitted-relationship checker by stating the judgment is based on what the link asserts.

  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 clearly frames the tool as a semantic validator for relationships and explicitly says it is not a permitted-relationship table lookup. It does not name sibling alternatives, so an agent must infer when to use it, 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.

• add_work_packageA
  4.2/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 and does disclose meaningful behavior: unknown dependency ids and cycles are rejected, and a benefit without an owner produces a warning. It does not, however, state whether updates are partial or full replacements or what happens when an id does not exist, which are significant traits 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.

  Conciseness4/5

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

  The description is compact: one sentence for the action, one for the id branch, one for validation behavior. The bilingual duplication doubles the length but keeps each language self-contained, and there is no fluff. Slightly below 5 because the title 'Add or update a work package' already overlaps with the first sentence.

  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 an 18-param mutation tool with no annotations and no output schema, the description covers the core upsert and error/warning semantics but leaves gaps: no return shape, no update-replacement semantics, and no guidance on updating a nonexistent id. It is minimally viable but not fully complete for such a complex 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 description coverage is 89%, so the schema already documents most parameters and the baseline is 3. The description adds real meaning beyond the schema by explaining that id switches add/update mode and by exposing validation coupling between dependsOn, benefit, and benefitOwner. That justifies a 4.

  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 names a specific verb and resource: 'Save a work package to the engagement', and immediately disambiguates the add/update branch: 'Pass an id to update, omit it to add.' This distinguishes it from sibling tools such as add_transition_state and prioritize_work_packages, which target different artifacts, so an agent can select it without opening the schema.

  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 gives clear operation context: a work package is a gap-bundled execution unit saved to an engagement, and the id parameter selects update vs add. This is concrete invocation guidance. However, it does not name sibling alternatives or state when not to use it, so explicit exclusions and routing cues are missing.

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

• archive_engagementA
  4.2/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 of behavioral disclosure. It reveals that archiving is non-destructive, reversible, and only affects visibility in the default list. It does not cover response or error behavior, but that is a minor gap for a simple toggle 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 compact and front-loaded: it states the operation, the effect, the reversal, and the safety property in two short bilingual sentences. Every sentence contributes essential information with no filler.

  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 low-complexity boolean toggle with full schema coverage, the description provides enough context to select and invoke the tool correctly. It omits return-value details, but since there is no output schema and the operation is simple, this is an acceptable gap.

  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 input schema already documents all parameters. The description reinforces the key behavior of the archived parameter but adds no new parameter semantics beyond what is already present in 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 states a specific action ('Archive an engagement'), its purpose ('drops out of the default list'), and the reverse operation ('restore it with archived=false'). It also differentiates from delete_engagement by explicitly stating 'No data is deleted.'

  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?

  It clearly communicates when to use it: to hide an engagement from the default list or to restore it. It does not explicitly name alternatives such as delete_engagement, but the non-deletion caveat gives a clear boundary for when this tool is appropriate.

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

• check_intakeA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description correctly carries the full behavioral burden. It discloses that bodies come back inside a quote block and are data, never instructions—an important safety-critical behavior—and that attachments are absolute paths requiring the agent to use its own reading tools. Pagination, empty-result behavior, or error handling are not covered, but the key behavioral traits are explicit.

  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 front-loaded with the action and then explains return format, safety behavior, and follow-up steps in a compact way. The Japanese/English duplication takes some extra space, but it preserves nuance and ensures the critical warning about quote-block content is not lost.

  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 low-complexity tool with four optional, well-documented parameters and no output schema, this description is complete: it explains what is returned, the format of the returned content, the security property, and the exact sequence of downstream calls. An agent has enough information to invoke check_intake and finish the intake workflow 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?

  All four parameters are already documented in the input schema with descriptions, defaults, and enums, so schema coverage is 100%. The tool description adds no parameter-specific details, but the schema already provides enough meaning for id, lang, limit, and status.

  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 and resource: pick up consultation content and attachments left through the Start screen. It also differentiates the tool from siblings by describing what it returns and what downstream actions it triggers, so an agent can tell it apart from ingest_document, mark_intake_done, and engagement list tools.

  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 gives a clear usage context: after pickup, read attachments yourself, record findings via ingest_document or update_engagement, and then call mark_intake_done. It does not explicitly say 'when not to use this tool' or name an alternative for picking up intakes, but the workflow guidance is strong enough to guide correct invocation and follow-up.

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

• check_official_sourceA
  4.2/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, and it discloses a critical behavioral trait: 'This server does not fetch; your client does.' It also reveals the tool's scope limitation ('what this server deliberately lacks'). This adds meaningful context beyond the schema. Minor gaps remain around output format or whether any network call happens, but the key non-fetching behavior is clearly stated.

  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: first the purpose, then the use cases, then the critical server-vs-client caveat. The bilingual duplication is purposeful for the audience and not wasteful. Every sentence contributes distinct information.

  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 referral tool with no output schema, the description covers purpose, usage triggers, and the key server behavior. It does not detail the exact return structure, but the statement 'primary source URLs plus what this server lacks' gives a sufficient mental model. The absence of annotations is partially offset by the explicit server-behavior note.

  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%, and both parameters (lang, topic) are already well-described in the schema with examples and enums. The description does not add extra parameter-level detail, which is acceptable given the schema's completeness. Baseline 3 applies.

  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 states a specific verb ('Return') and a precise resource ('primary source URLs for a topic, plus what this server deliberately lacks'). It clearly distinguishes this tool from siblings like search_togaf or reference by emphasizing that it returns authoritative sources rather than fetched content. The bilingual phrasing reinforces the same meaning without ambiguity.

  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 gives explicit trigger conditions: 'when you doubt an answer here, suspect a newer edition, or need authoritative wording.' This is clear context for when to use the tool. However, it does not name alternatives or state when not to use it, so it stops short of the highest bar.

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

• create_engagementA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral disclosure burden. It openly states the key side effects: the new engagement becomes current and existing engagements are preserved. This is valuable transparency, though it does not cover failure modes, permissions, or 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?

  The description is short, front-loaded with the core action, and contains no filler. The bilingual duplication is intentional and each sentence contributes meaningful behavioral information.

  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 create operation with a fully documented schema and no output schema, the description covers the important state-changing behavior: creating, selecting as current, and preserving existing engagements. It is complete enough for an agent to understand what happens, though it does not mention what the tool returns or how current selection is later changed.

  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 input schema already documents all seven parameters thoroughly. The description adds no parameter-specific detail, which is acceptable under the baseline but does not improve upon 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 a specific action: create an additional engagement and make it current. It also distinguishes this from updating, listing, or switching by emphasizing that existing engagements are kept, so the tool's purpose is unambiguous even among many engagement-related siblings.

  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 clear situational context: use this when you want an additional engagement while keeping existing ones running in parallel. It does not explicitly name alternatives or state when not to use it, so it falls just short of full explicit routing guidance.

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

• diagram_application_landscapeA
  4.2/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, and it discloses the output format (Mermaid diagram), the analysis performed (connection counts), and the warning threshold (15 interfaces). It does not explicitly state whether the tool has side effects, but the return-oriented wording and diagram-generation behavior make the tool's behavior sufficiently 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?

  Everything is front-loaded: first clause names the output, second states the analytical extra, third gives the business context. The bilingual text is efficient and every sentence adds information; nothing is filler.

  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 diagram-generation tool with all-optional params and no output schema, the description tells the agent what the returned artifact is, what analytical extras it includes, and when it belongs in the workflow. It could mention behavior for empty input or missing layer assignments, but those are minor gaps given the sparse but clear schema.

  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 each parameter already has bilingual descriptions and defaults, so the schema carries the semantic weight. The description does not add per-parameter guidance, but it does add domain context (layers, interface threshold) that helps the agent choose values, so baseline 3 is appropriate.

  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?

  States a specific action and resource: draws applications and interfaces as a layered Mermaid diagram. The added analysis (most-connected apps, >15 interface warning) and the Phase C baseline purpose give a distinctive purpose that separates it from sibling diagram tools like diagram_capability_map or diagram_c4_context.

  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?

  Clearly contextualizes use: it turns the Phase C baseline into a discussable picture, so an agent can infer when to choose it during architecture landscape work. It does not explicitly name sibling alternatives or state when not to use them, but the Phase C framing is enough guidance for most calls.

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

• diagram_value_streamA
  4.2/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 and discloses the output format (Mermaid, left-to-right), the hierarchical 'hanging' of capabilities under stages, and the flagging of stages with no capability attached. It stops short of edge-case behavior (empty stages array, unknown name) but adds genuinely useful behavioral context beyond a generic 'draws a diagram.'

  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 compact sentences per language, with the core function in the first sentence and the usage insight in the second, and zero filler. The bilingual duplication is justified by the lang parameter supporting ja/en/both.

  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 tool with no output schema and no annotations, the description conveys the return value (a Mermaid diagram), how stages and their capabilities map into it, and the special flagging behavior. Minor gaps remain: behavior with the default empty stages array and whether name is a label or must reference existing data.

  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%, so the schema already documents name, lang, and stages as the baseline. The description adds behavioral meaning beyond the schema by explaining the consequence of the capabilities array (hung under each stage) and of an empty array (the stage gets flagged), tying the stages structure to visible diagram behavior.

  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?

  States a specific verb+resource ('Draw a value stream left to right in Mermaid') plus two distinguishing behaviors: hanging supporting capabilities under each stage and flagging stages with no capability attached. This clearly separates it from sibling tools like diagram_capability_map, value_stream_method, and diagram_application_landscape.

  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 only usage context is 'Paired with the capability map it shows which capability in which stage is weak,' which implies a combined-analysis scenario but never names alternatives or exclusions among the many sibling diagram tools. An agent gets no explicit guidance on when to choose this over diagram_capability_map or draft_capability_map.

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

• export_reportA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral disclosure burden. It explicitly reveals the file-writing side effect and important format traits (self-contained HTML, print CSS, no external references), plus the return contract. It omits failure/error behavior when overwrite is false or when outputPath is invalid, but the schema's overwrite description partially covers that.

  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, information-dense sentence with no filler. The bilingual duplication is the only repetition, but it is reasonable for a ja/en tool.

  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?

  It is complete enough for a simple export tool: all 4 parameters are fully described in the schema and the description covers the output format, the return value (path, size, open instructions), and the artifact constraints. It falls just short of fully complete because it does not address overwrite-conflict or invalid-path behavior explicitly and no output schema exists.

  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 minor value beyond the schema by detailing what 'html' output means (self-contained, print CSS, no external references), but it adds nothing about lang, overwrite, or outputPath beyond their schema entries.

  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 names a specific verb ('Write'), a specific resource ('current engagement dashboard'), and the exact delivered artifact (Markdown or self-contained static HTML). It clearly differentiates from sibling display tools like get_dashboard and open_dashboard by emphasizing file output and return metadata.

  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?

  It gives clear context: use this tool when the current engagement dashboard must be saved to a file, and the returned path/size/open instructions make the post-call flow explicit. It does not explicitly name when-not-to-use or compare with export_deliverable, so it stops short of a 5.

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

• open_startA
  4.2/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 discloses that the tool opens a browser form, returns a URL, rides on the same local HTTP server on 127.0.0.1, and that submitted items are picked up via check_intake. This gives useful behavioral context beyond a simple 'open screen' statement.

  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 concise and front-loaded, with the core purpose stated first. The bilingual repetition is mildly redundant but justified by the tool's ja/en audience. Each sentence contributes relevant information such as the server, return value, and workflow linkage.

  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 tool with two optional parameters and no output schema, the description is complete: it states what the tool does, where it runs, what it returns, and how the submitted material is subsequently accessed. Nothing essential is missing for correct invocation.

  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 both parameters fully with descriptions and defaults, so the description does not need to compensate. It adds no additional parameter-level meaning, but the baseline of 3 is appropriate given 100% 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 identifies a specific verb (open), a specific resource (Start screen), and its purpose: a browser form for handing over a question plus files. It also distinguishes itself from related tools by noting it returns a URL and rides on the same local server as the dashboard.

  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 clear context for when to use this tool: when you need to hand over consultation content and files via a browser-based Start screen. It also refers to check_intake as the downstream pickup step, giving workflow context. It does not explicitly name alternatives to avoid, but the use case is clear enough for an agent to select it.

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

• recommend_frameworksA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description takes on the behavioral disclosure burden. It explains the output is ranked, includes adjacent framework pairing, and explicitly returns a 'TOGAF alone is enough' answer in the right case. It could go further by stating read-only behavior or ranking criteria, but the core behavior is 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?

  The description is compact: two short sentences per language, with the main behavior front-loaded and the fallback condition second. There is no filler or redundant content.

  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?

  The description covers the input type, the output shape, and the special fallback case, which is sufficient for a recommendation tool without an output schema. It could be slightly richer with an example of a returned recommendation, but nothing essential is missing.

  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 parameters are already well documented in the schema. The description only rephrases the 'need' parameter and adds no extra meaning beyond what the schema provides.

  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 names a specific verb and resource: from a free-text need, return which part of TOGAF to use and which adjacent frameworks to pair with it, ranked. This clearly distinguishes the tool from siblings, since no other sibling claims this recommendation function.

  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?

  It states the clear input context: a free-text need, and it even defines the fallback behavior when TOGAF alone is enough. However, it does not explicitly name alternatives or say when not to use this tool, so it stops short of a 5.

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

• search_togafA
  4.2/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the behavioral burden. It discloses the cross-domain scope and bilingual support, and notes `reference` is faster for known IDs. However, it does not state the result format, pagination limit behavior, or explicitly confirm that this is a read-only operation. No contradiction with annotations exists.

  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 compact sentences, front-loaded with the action and scope; the sibling routing hint is placed second. No redundant filler given the bilingual audience, and each sentence earns its place.

  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 search tool with a fully documented schema and a key routing hint to `reference`, the description is nearly complete. The missing explicit return-format description is a minor gap given no output schema, but it does not prevent an agent from invoking the tool 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 covers 100% of parameters with descriptions, so baseline 3 applies. The description adds no new parameter detail beyond restating the searchable kinds, which the schema already enumerates via the `kinds` enum.

  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?

  Describes a specific verb ('Search') and resource ('phases, techniques, deliverables, and the glossary' in the TOGAF knowledge base), and explicitly contrasts with `reference` for ID-known lookups. This differentiates it from the sibling tool sufficiently.

  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?

  Explicitly tells agents to use `reference` when the ID is already known, and implies search for keyword-based cross-domain queries. This is clear when-to-use guidance relative to the most relevant sibling.

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

• suggest_archimate_viewA
  4.2/5.0
  Behavior4/5

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

  With no annotations available, the description carries the full burden and it does disclose the behavioral nature: it returns a proposed view plan, not a rendered diagram, and includes explicit criteria for completion and exclusions ('what must stay off the page'). This conveys the advisory, non-modifying nature of the 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, well-structured English sentence (plus a Japanese equivalent) that front-loads the core purpose and then lists the output components. Every phrase adds value and there is no redundant filler.

  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 no output schema, the description sufficiently explains the return value by enumerating the key parts of the proposed view: layers, elements, layout, relationships, completion criteria, and exclusions. It lacks only minor contextual details such as return format or handling of ambiguous concerns, but overall it is complete enough for correct 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?

  Schema description coverage is 100%, so the schema already documents all three parameters. The description reiterates that 'concern' is a free-text stakeholder concern but does not add new meaning beyond what the schema provides.

  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 uses a specific verb ('propose'/'suggest') with a clear resource ('an ArchiMate view') and explicitly defines the scope: layers, elements, layout, relationships, completion criteria, and exclusions. This clearly distinguishes it from sibling diagram-generation tools, which actually render diagrams.

  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 clearly states the input condition ('from a free-text stakeholder concern') and the intended outcome, so an agent can infer when to use it. However, it does not name alternatives or state when not to use it, such as when a rendered diagram is needed instead of a view plan.

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

• about_knowledgeA
  4.3/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, and it does well by disclosing that the tool reports limitations ('何を持っていないか'), provenance ('何に基づき'), and freshness ('いつ一次情報と突き合わせ'). This makes the tool's scope and boundaries clear, though it does not describe output structure or side effects, which are minimal for an informational 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: the first clause states the core content, and the second adds the pointer to authoritative wording. Nothing is wasted, and the bilingual format is acceptable given the language-aware parameter.

  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, read-only meta-information tool with one optional parameter and no output schema, the description covers all essential context: what the tool tells you, how fresh the knowledge is, what it lacks, and where to find authoritative text. No critical information is missing for an agent to invoke 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?

  The single optional parameter `lang` is fully documented in the schema with an enum and a description ('出力言語 / Output language'), so schema coverage is 100%. The tool description adds no additional meaning about the parameter, so the baseline score of 3 applies.

  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 names the resource ('this knowledge base') and the precise dimensions it covers: basis, freshness/date of last check, gaps, and pointer to authoritative wording. This clearly distinguishes it from siblings like whats_new_for_me and check_official_source even though no alternatives are named.

  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?

  It states a clear context for use: when an agent needs to know what the knowledge base is founded on, how fresh it is, what it lacks, or where to get the original wording. It gives one explicit conditional use-case, '原文が必要なとき' (when the original text is needed), but does not mention when not to use it or name alternative tools.

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

• business_architecture_antipatternsA
  4.3/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 behavioral burden. It discloses that the tool returns a three-part structure (symptom, consequence, fix), implies a read-only informational behavior, and states both pre-build and review applications. It does not discuss edge cases or assumptions, but the behavior is straightforward and adequately 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?

  The description is succinct, bilingual without redundancy, and front-loads the core value ('anti-patterns as symptom, consequence, fix') followed by the two use cases. Every sentence earns its place.

  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 one-parameter informational tool with no output schema, the description fully explains what the tool returns, in what format, and when to use it. Nothing essential for invoking it correctly is missing.

  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 single parameter 'lang' has 100% schema coverage including an enum and a bilingual description. The tool description adds no parameter-level detail, but none is needed because the schema fully documents the parameter. Baseline 3 is appropriate.

  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 uses a specific verb ('Return') and names the exact resource ('recurring ways business architecture goes wrong') plus the output structure (symptom, consequence, fix). This clearly distinguishes it from sibling capability-map and review tools by focusing on anti-patterns rather than diagrams, methods, or checklists.

  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 explicitly gives two usage contexts: before building and when reviewing an existing artefact. It does not name specific alternatives or exclusions, but the intended timing is clear enough for an agent to select it appropriately among the many sibling tools.

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

• summarize_document_for_architectureA
  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 behavioral burden. It candidly discloses that the scan only inspects keywords and sentence endings, that it is worse than the client's own reading, and that the output is structured material with line numbers and missing-viewpoint follow-ups rather than a summary. Some details about the exact output format or viewpoint set are absent, but the key behavioral traits are clearly exposed.

  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 front-loaded with the verb and resource, then the output shape, then the anti-goal. It is efficient and has no filler, though the Japanese and English sections mirror each other closely, adding some length. Still well-structured and readable.

  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 no output schema and no annotations, the description explains the core return value: matched excerpts with line numbers per viewpoint, plus guidance for uncovered viewpoints. It also documents the important text-input caveat. It is not exhaustive about the exact viewpoint taxonomy or response structure, but it gives an agent enough context 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?

  Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema by clarifying the two input modes (path vs text) and warning that text reuse does not boost accuracy. This elevates it above mere schema repetition.

  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 states a specific action and resource: inventory a document against architecture viewpoints and return line-numbered excerpts per viewpoint. It also explicitly distinguishes itself from a prose summary ('要約そのものではなく / rather than a prose summary'), making it clearly different from sibling read/extract/ingest tools.

  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 gives clear guidance on when to use path vs text, and explicitly warns that pasting already-read text will not improve accuracy and is only useful for mechanical formatting. It does not explicitly name sibling tools as alternatives, so it stops short of full when-not-to-use guidance.

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

• switch_engagementA
  4.3/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 and it does important work: it reveals that switch_engagement is stateful and affects subsequent tools. This is a non-obvious behavioral consequence that an agent must know before invoking. It does not discuss scope, persistence, or failure behavior, but the core side effect is clearly disclosed.

  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: it states the action first and then gives the crucial effect on downstream operations. Both language versions earn their place, and there is no redundant filler.

  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 two-parameter tool with no output schema, the description covers what an agent needs to invoke it correctly: what it does and what consequences follow. No critical operational context is missing.

  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 both parameters are already documented in the schema. The tool description adds no additional meaning about engagementId or lang beyond what the schema provides, so 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.

  Purpose5/5

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

  The description uses a specific verb ('switch') and a clear resource ('current engagement'), then explains the consequence: later read and update tools operate on the newly selected engagement. This distinguishes it from sibling CRUD tools like get_engagement, update_engagement, and create_engagement.

  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 clearly indicates that this tool changes the active context for subsequent operations, which tells an agent when it should be used: before a sequence of engagement-scoped reads/updates. It does not explicitly state exclusions or name alternatives, but the behavioral context is enough to avoid confusing it with get_engagement or list_engagements.

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

• export_archimate_csvA
  4.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 behavioral disclosure burden. It discloses that files are written to disk, the exact CSV set produced, what fromEngagement: true adds, and that the reply includes import steps. It does not cover failure behavior, but overwrite semantics are already in the schema.

  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 compact bilingual sentences front-load the core operation, then the special flag behavior, then the reply payload. Every clause adds information and there is no filler or repetition of the title.

  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 tool with 8 optional parameters and no output schema, the description covers the primary side effects, the exact output files, and the reply behavior. Parameters are fully documented in the schema; the only minor gap is the lack of an explicit description of the full return value beyond the import steps.

  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%, so the baseline is 3. The description adds meaningful semantics beyond the schema by enumerating what fromEngagement: true turns into elements (stakeholders, concerns, transition states, capabilities, work packages, benefits, deliverables), which helps an agent decide whether to set the flag.

  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 states a specific action — writing an ArchiMate model to disk as the Archi CSV import set — and names the exact file set (elements/relations/properties.csv). This differentiates it from sibling export_archimate_open_exchange by format and purpose.

  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 clearly establishes context: use this when you need Archi-importable CSV output, and the reply includes Archi import steps. It does not explicitly name sibling alternatives or state when not to use it, but the intended use case is clear enough for routing.

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

• gap_analysisA
  4.4/5.0
  Behavior5/5

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

  With no annotations, the description carries full behavioral burden, and it is highly transparent. It discloses that eliminations are always reported to preserve the cost-reduction case, that gaps are emitted as ready-to-paste add_work_package JSON, that save=true only appends a one-line summary without creating work packages, and that missing sources are rendered as 'no source' rather than blank.

  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 information-dense and well structured: method, key guarantee, downstream integration, side effects, and provenance behavior are covered in order. The bilingual duplication makes it longer than strictly necessary, but each clause adds behavioral value and nothing is filler.

  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 complex 7-parameter tool with no output schema and no annotations, yet the description explains the method, the matrix output, the gap categories, the recommended-action return, the add_work_package JSON emission, the save side effect, and the sources edge case. An agent has enough context to invoke the tool correctly and interpret its results.

  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 description coverage is 100%, so the baseline is 3, and the description adds meaningful semantic value beyond the schema. It clarifies the behavior of sources (source column, 'no source' marker), the side effect of save (appends summary, does not create work packages), and the default mapping semantics for unmapped baseline elements (retained if same-named target exists, otherwise eliminated).

  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 compares baseline and target elements, visualizes the mapping as a matrix, and derives gaps (new, eliminated, modified/replaced) with recommended actions. This is a specific verb+resource and meaningfully distinguishes gap_analysis from siblings like compare_with_togaf or cross_map.

  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 use case is clearly implied: call this when you need a baseline-to-target gap analysis with a mapping matrix and gap list. However, the description never explicitly names alternatives or states when not to use this tool versus siblings like compare_with_togaf or cross_map, so the guidance is implied rather than explicit.

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

• ingest_documentA
  4.4/5.0
  Behavior5/5

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

  With no annotations, the description carries the full safety burden and does so well: it explicitly states 'apply=false previews only and writes nothing' and 'With apply=true each item is stored with its source reference'. It also discloses the scanner's limitation (keyword/sentence-ending scan is worse than the agent's own reading) and the duplicate-title skip rule, which are not inferable from the schema.

  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 main purpose, default behavior, persistence switch, and duplicate rule are contained in two front-loaded sentences, followed by a focused caveat about the text parameter. The bilingual format duplicates content, but both halves are compact and every sentence carries operational information.

  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 write-capable tool with 6 parameters and no output schema, it covers the important decision points: preview vs persist, path vs text, duplicate handling, and source references. The main gaps are no description of the returned preview/result format and no explicit mention of an active-engagement prerequisite, but these do not block correct invocation.

  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?

  All parameters already have schema descriptions (100% coverage), so the description only needs to add value. It does: it explains the path/text exclusivity, warns that pasting already-read text does not improve accuracy, and clarifies that source labels appear in the source column. That advice goes beyond the schema's declarative 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?

  States the core action as a specific verb+resource: 'Ingest candidates extracted from a document into the current engagement.' The 'current engagement' scope and the ingest-vs-extract action distinguish it from sibling tools such as extract_from_document and read_document without ambiguity.

  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?

  Gives clear operational context by describing the preview default and the apply=true persistence behavior, and advises when the text parameter is or is not useful. However, it never explicitly tells an agent when to choose ingest_document over sibling tools such as extract_from_document or read_document, and it does not state prerequisites such as having an active engagement.

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

• start_hereA
  4.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 behavioral disclosure burden. It discloses conditional behavior (no engagement vs engagement), the output format (a single screen), and the effect of passing a goal. It does not explicitly mention side effects or auth, but the described behavior strongly implies a non-destructive summary tool, which is adequate for this role.

  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 bilingual description is compact and efficient. The first sentence front-loads the entry-point role and the core conditional behavior, followed by the goal hint and a direct usage instruction. Every sentence earns its place with no redundant filler.

  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 orientation tool with no output schema or annotations, the description is complete enough: it tells the agent what to expect in both engagement states, how the optional goal affects the result, and when to call it. It lacks an explicit statement of return structure or error behavior, but these are not critical for an entry point that returns a screen.

  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 description coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by explaining that passing a goal 'gives a tailored read', which clarifies the behavioral effect of the optional parameter. It doesn't add anything about lang, but that parameter's schema description is already sufficient.

  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 the server's entry point, with a specific verb ('returns') and resource, and explains its conditional output: three things to settle first if no engagement, or current status and three weekly tasks if an engagement exists. It distinguishes itself from the many sibling tools by its role as the initial call and its high-level, orientation-focused purpose.

  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 explicitly states '迷ったら最初にこれを呼ぶ / Call this first when unsure', giving a clear condition for use. It does not name alternatives or say when not to use it, but for an entry point the first-call guidance is strong contextual direction that helps an agent decide when to invoke it.

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

• delete_engagementA
  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 full behavioral burden. It clearly discloses that deletion is permanent, irreversible, and requires confirm=true, which are the critical destructive traits. It does not mention return values or side effects, but it covers the most important behavioral context for a destructive 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: it opens with the irreversible deletion warning, states the required confirmation flag, then gives the alternative. Both bilingual halves earn their place 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?

  For a destructive single-resource tool with full schema documentation, the description is complete enough. It covers the irreversible nature, the required confirmation, and the alternative archive path, leaving no critical decision unclear for the 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 coverage is 100%, so the input schema already documents all three parameters, their defaults, and the meaning of confirm. The description reinforces the confirm requirement but does not add substantial meaning beyond the schema, so the baseline of 3 is appropriate.

  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 states a specific verb and resource: it permanently deletes an engagement. It also explicitly distinguishes itself from archive_engagement, so an agent can tell this tool apart from the closest sibling without opening schemas.

  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 gives clear usage guidance by warning that the action cannot be undone and that confirm=true is mandatory. It explicitly directs the agent to archive_engagement when preservation is intended, providing a concrete alternative with a condition.

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

• draft_capability_mapA
  4.5/5.0
  Behavior4/5

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

  There are no annotations, so the description carries the burden. It is candid about limitations: it deliberately does not ensure content correctness, and it refuses to infer industry from the description due to past misjudgments. It also states that industry sets apply only with an explicit parameter; however, it does not disclose output format details or whether the draft is persisted/visible to the business, so a 4 is appropriate.

  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 somewhat long but all content is functional; the core purpose and the key caveat come first in both languages, and the sibling tool comparison is useful. The dual-language structure is slightly repetitive but serves this bilingual tool appropriately.

  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 drafting tool with no output schema and no annotations, the description covers the main points: what the output contains, how to use it, when to use the alternative, and how the industry parameter behaves. It does not specify whether diagrams are editable or persisted, but given the large sibling set and the parameter richness in the schema, this is close to complete.

  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 already has 100% coverage with detailed Japanese/English descriptions for all three parameters, so the schema does the heavy lifting. The description adds decision-relevant context beyond the schema: it tells the agent that industry sets are applied only when `industry` is explicit (schema says omit and no set is applied, but description explains the rationale), and it frames businessDescription concreteness as a quality lever. That is meaningful but modest value 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 drafts a level-1 capability map (diagram + table) plus questions to ask the business side. It explicitly says it produces shape and questions, not correct content, and even names the faster alternative, check_capability_map, so its purpose is unambiguous and distinct from siblings.

  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 says when to use this tool versus the faster and more accurate alternative, check_capability_map: use this when you want the shape and questions; if you've read the source material, pass your own names to check_capability_map. It also clearly states when industry sets apply—only when the `industry` parameter is passed explicitly, not inferred—and that omission merely suggests candidates.

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

• security_requirements_checklistA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and fully discloses behavior: it reads exposure, data sensitivity, scale, and operating arrangement from `scope`, selects prioritized items with reasons, appends scope-specific concerns, handles regulated vs. non-regulated cases, and returns writing guidance when `scope` is omitted. Nothing about the tool's behavior is left to guesswork.

  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 lengthy and bilingual, but every clause carries functional weight: core purpose, scope analysis, prioritization, scope-specific additions, regulation behavior, and fallback. The main purpose is front-loaded, and the duplication between languages is not filler—it ensures clarity for either language context.

  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?

  Even without an output schema, the description specifies the return content (checklist items with verification methods, prioritized items with reasons, scope-specific additions) and all edge cases (regulated true/false, scope omitted). It does not specify the exact data format of the response, but that is a minor gap given the detailed behavioral description.

  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%, so baseline is 3. The description adds value beyond the schema by explaining what `scope` should contain (public exposure, data sensitivity, scale, operating arrangement) and how `regulated=false` still triggers flags for personal data or payments. This helps the agent construct better parameter values.

  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 states a specific verb (返す / returns) and a clear resource: a security-requirements checklist with verification methods. It further differentiates the tool by explaining that it prioritizes which items to start with and adds scope-specific concerns, distinguishing it from siblings like generate_review_checklist or threat_model_starter.

  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 gives concrete conditions: setting `regulated` to true adds regulatory items, while false still flags personal data or payments, and omitting `scope` returns guidance on what to write. It does not name sibling alternatives explicitly, but these behavioral conditions effectively tell an agent when 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.

• threat_model_starterA
  4.5/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full behavioral burden and does so richly. It discloses that the matrix is filled and prioritized rather than blank, that it returns evidence-based inferences, the three cells to fill first, likely attack realities per lens, missing input information, and that the output is explicitly a draft to be settled with a security owner.

  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 long but every sentence earns its place: purpose, output contents, situation-dependent behavior, and draft status are all packed densely and the main outcome is front-loaded. The bilingual repetition is justified by the tool's own language parameter and is not filler.

  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 complex generative/analysis tool with no output schema and no annotations, the description is unusually complete. It specifies what is returned, what is not returned (blank cells), how it varies by context, what it will flag as missing input, and the status of the output.

  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 schema already documents lang, actors, assets, and system well. The description reinforces the value of a detailed system description and mentions the omitted-system fallback, but adds little parameter-specific meaning beyond what the schema provides.

  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 states a specific verb and resource: reading a system description and building a threat-modelling starting point, with the specific six-lens STRIDE matrix and prioritized outputs. It clearly distinguishes this tool from security-adjacent siblings such as security_requirements_checklist and review_security_posture by focusing on threat-model draft generation.

  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 gives clear context for use: it fits situations where a system description exists and a threat-model starting point is needed, and it notes that different exposure contexts (public portal vs isolated IoT) change the output. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.

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

• inspect_findingsA
  4.6/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden — and discharges it completely. It discloses the input boundary (server never reads the material), the output framing (every finding phrased as a possibility and paired with item numbers), the heuristics (rounding-explained differences downgraded, same-source conflicts specially noted, start-after-end date ordering weighted high), unreadable-value handling with reasons, and the zero-result contract that explicitly disclaims correctness and lists human-only lenses. Nothing about the tool's behavior is left to guesswork.

  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 — roughly 400 words across the bilingual text — but the tool's complexity justifies most of it. The core purpose and the critical constraint (server never reads the document) are front-loaded, and the seven checks follow a consistent, scannable structure; the bilingual duplication and granular parentheticals cost some conciseness but serve the ja/en audience and encode genuinely useful heuristics.

  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 no output schema, the description explains the return contract thoroughly: numbered findings referencing both item numbers, weak vs. high-weighted date-order findings, unreadable-value reports with reasons, and an explicit zero-result message with human-review lenses. The seven-check enumeration plus edge-case handling (rounding, same-source, unit ambiguity) covers the full behavioral surface of a high-complexity tool; the only unspecified detail is the exact JSON shape of the output, which the semantic detail renders non-critical.

  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 high, so the baseline is 3, but the description adds meaning the schema lacks — most notably for `value`, which has no schema description at all: it specifies how values are interpreted (numeric with Japanese magnitude/qualifier/rounding parsing, date reading for date-like strings) and what happens when parsing fails. It also ties `subject` and `confidence=inferred` to specific checks, connecting each parameter to the behavior that consumes it.

  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 title and opening sentence name a specific verb and resource — mechanically cross-checking the list of items you structured after reading material — and enumerate precisely the seven checks performed. It is self-evidently distinct from all 70+ siblings: no other tool concerns contradiction checking of structured findings, and the 'server never reads the document' clause separates it from the document-reading siblings such as read_document and extract_from_document.

  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?

  It clearly states the trigger context: use it on the items you structured after reading material, and the opening framing implies the tool is for post-reading verification rather than document access. The 'server never reads the document' clause is an implicit when-not, but no alternative tools are named, and the boundary against validation siblings like check_capability_map or analyze_text_with_claude is left for the agent to infer.

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

• referenceA
  4.7/5.0
  Behavior5/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 reveals that omitting id returns a list, passing id or name returns one entry, `within` narrows only for certain subjects, and the five other subjects return an error rather than silently ignoring `within`. That explicit error-handling disclosure goes well beyond what the schema alone states.

  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 dense and front-loaded with the core usage pattern: choose a subject with `of`, omit id for a list, pass it for one entry. It is long partly because of intentional bilingual repetition and the detailed subject enumeration, but each part contributes useful routing or selection information, so the length is justified rather than wasted.

  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 4-parameter lookup tool with no annotations and no output schema, the description covers the subject menu, list-versus-entry behavior, language selection, narrowing rules, and error behavior. The main gap is that it does not describe the shape or fields of the returned entries, which would be more valuable precisely because no output schema is provided.

  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%, so the schema already documents all parameters. The description still adds meaningful semantics by explaining the id behavior (list vs single entry, id or name accepted), detailing the subject categories (e.g., framework examples and the six security layers), and clarifying the role of `within`. This exceeds the baseline expected when the schema already covers everything.

  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 a specific verb and resource: one tool to look up TOGAF, ArchiMate, and security knowledge. It clearly distinguishes the two modes (omit id for a list, pass id for a single entry) and explicitly contrasts itself with search_togaf ('あちらは横断検索、こちらはピンポイント取得'), so an agent can separate it from the closest sibling without opening the schema.

  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 states when to use each mode and gives an explicit routing rule: when the id is unknown, use search_togaf first, since that tool searches across subjects while this one fetches a specific entry. It also explains when `within` is allowed and which subjects reject it, providing clear selection and exclusion guidance.

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

• extract_from_documentA
  4.9/5.0
  Behavior5/5

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

  With no annotations provided, the description fully carries the behavioral burden and does so well. It discloses that the tool performs mechanical keyword and sentence-ending scanning, does not read or understand the document, is lossy, writes nothing, and returns output with source line numbers and register-ready JSON. It also warns that pasting already-read text will not improve accuracy, which is valuable behavioral context beyond the schema.

  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 front-loaded with the core operation and the no-write guarantee, followed by a clearly emphasized limitation and three concrete use cases. Although it is bilingual and somewhat long, the repetition serves the tool's ja/en audience, and every sentence adds either capability, limitation, or usage guidance. Nothing is filler.

  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 tool with no output schema and no annotations, the description is remarkably complete. It tells the agent what the tool returns (Markdown table with source line numbers and update_engagement JSON), what it cannot do (understand the document), when to use it, when to avoid it, and how the parameters behave, including the path/text exclusivity and truncation reporting. The agent can decide correctly whether and how to invoke it.

  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 description coverage is 100%, so the baseline is 3, and the schema already documents all six parameters. The description adds meaningful semantic context beyond the schema, especially for the text parameter: it warns that pasting already-understood text does not improve accuracy and clarifies that text is useful only for mechanical formatting into line-numbered tables and JSON. This goes beyond what the schema states.

  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?

  Describes a specific operation: mechanically extract engagement material candidates (risk, stakeholder, system, requirement, action) from a document and return a Markdown table with source line numbers plus JSON for update_engagement. The explicit statement that it does not read or understand the document sharply distinguishes it from sibling document tools like read_document, ingest_document, and summarize_document_for_architecture.

  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?

  Gives explicit when-to-use guidance: it is appropriate only for (1) scanning files too large for the conversation, (2) recording skipped lines and reasons, and (3) producing register-ready JSON with citations. It also explicitly says when not to use it: if the agent can already read the full text, the agent should do candidate selection itself because this tool is a lossy inferior version.

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