RCA-MCP Connector

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v4.1.13
Disambiguation5/5
Each tool has a distinct purpose, clearly indicated by the hierarchical naming scheme. Overlaps are minimal; for example, rca_analysis_run and rca_analysis_run_async are complementary, not ambiguous.
Naming Consistency5/5
All tools follow a consistent pattern: 'rca_<domain>_<action>_<optional_specific>' in snake_case. This makes the tool surface predictable and easy to navigate.
Tool Count3/5
56 tools is high, but the server covers a broad domain (auth, graph management, multiple analysis methods, model lifecycle, reporting, guide ingestion, decision trees). Some tools could be merged (e.g., guide_ingest and guide_ingest_pdf), so the count feels slightly bloated.
Completeness5/5
The tool set covers the full lifecycle of RC: from auth, graph creation/discovery, model management, various analysis methods (single, batch, ensemble, async), result querying and comparison, report generation, and even a knowledge base with decision trees. No major gaps are apparent.
Average 3.9/5 across 56 of 56 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 22 commits in the last 12 weeks
- Last stable release on July 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 6 times in the last 30 days.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the agent knows it mutates data. The description adds no further behavioral details (e.g., if edge must exist, side effects). Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundancy. Direct and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having output schema and moderate parameter count, the description omits critical context like edge existence, permission requirements, or error conditions. Leaves agent with many unknowns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameter meaning. It does not mention any parameter (source, target, graph_id, token), leaving their semantics entirely to 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?
Description explicitly states the action ('Remove') and the resource ('a directed edge from a causal graph'), which is precise and distinguishes from sibling tools like rca_graph_add_edge and rca_graph_remove_node.
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 use this tool versus alternatives (e.g., removing a node instead). Lacks context like prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds little beyond annotations: it states the action (advance model lifecycle) but does not explain idempotency, side effects, or validation of transitions. Annotations already mark idempotentHint=true and destructiveHint=false, so the description fails to provide extra behavioral context.
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?
Extremely concise: two sentences plus Args/Returns. Every sentence adds value without redundancy. No unnecessary words.
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 update tool with an output schema, the description covers basic functionality but misses details: it does not explain constraints on status transitions, mentions of token/client_id are absent, and the lifecycle sequence is incomplete (deprecated/failed missing). Adequate but with gaps.
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 0% at the top level (the 'params' parameter has no description). The description lists two of the four nested fields (model_id, new_status) and explains the return type, partially compensating. However, it omits 'token' and 'client_id', and does not clarify the allowed status values beyond the sequence.
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 verb 'Advance' and the resource 'model through its lifecycle', specifying the status sequence. However, it implies forward-only progression (draft→trained→validated→deployed), while the schema allows setting to 'deprecated' or 'failed', which are not part of the listed sequence, causing slight 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?
No guidance on when to use this tool versus siblings like rca_model_create, rca_model_validate, or rca_model_delete. The description does not mention prerequisites, alternatives, or context for status updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that it returns a JSON list, which is useful but not critical. It does not disclose additional behavioral traits like rate limits or authentication details.
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, with a front-loaded purpose and a clear parameter list. It is efficient and avoids unnecessary details.
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 the presence of an output schema, the description adequately explains input parameters and return format. However, it lacks details on pagination, multi-hour queries, or integration with sibling tools, making it insufficient for complex uses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description repeats the parameter meanings from the schema (token, hour_key) with the format for hour_key. However, it omits client_id from the schema. Since schema description coverage is 0% (likely meaning schema descriptions are insufficient), the description adds some value but not enough to fully compensate.
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 reads structured audit log entries for a given hour bucket, with a specific verb and resource. It is distinguishable from siblings like rca_admin_health (health) and rca_admin_purge_namespace (destructive). However, it does not explicitly differentiate from other read-oriented tools.
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 versus alternatives. It does not mention exclusions or prerequisites. For example, it does not note that this is a safe, read-only operation compared to rca_admin_purge_namespace.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds return format details, but omits that a 'token' parameter is required, which is a key behavioral input.
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?
Description is short and front-loaded with purpose, but its brevity leads to omitting important parameter details, making it less useful despite being concise.
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 list tool with good annotations, the description is adequate but incomplete: it does not explain the 'token' parameter's role (pagination vs. authentication) or how results are scoped.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description only explains 'limit' and 'offset', ignoring the required 'token' and optional 'client_id' parameters. This leaves critical parameter meaning unexplained.
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?
Clearly states it lists stored RCA result IDs with pagination, but does not distinguish from sibling tool 'rca_analysis_query_results' which may also return result IDs with filtering.
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 is implicit (to list result IDs), but no explicit guidance on when to use this tool versus alternatives like 'rca_analysis_get_result' or 'rca_analysis_query_results'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds return format details (total, sessions, diagnosis if resolved), which is useful but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and to the point, front-loads purpose. Emoji is minor but harmless. Could be slightly more structured.
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 four parameters and no schema descriptions, the description is too sparse. Missing authentication details and parameter semantics limits agent's ability to use it correctly, despite an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only two of four parameters (equipment_id, resolved_only) are mentioned; token and client_id are omitted. With 0% schema coverage, the description fails to adequately document all 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?
Clearly states 'List all diagnostic sessions' with specific verb and resource. Additional info on optional filters distinguishes it from sibling tools like rca_analysis_list_results or rca_dtree_start.
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 use this tool versus alternatives, no context about prerequisites or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states it returns a summary, which adds context beyond annotations. 'Run' implies mutation, consistent with readOnlyHint=false. But it does not disclose auth requirements (token param not explained), error behavior, or side effects. Annotations already cover basic safety profile.
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?
Four sentences front-loading purpose and return type, with an Args/Returns block. Efficient but the block could be integrated into prose. No redundancy.
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?
Covers max incidents, return JSON structure, and model usage. Lacks prerequisites (auth token), when to batch vs single, and error handling. Output schema exists but not described. Adequate but not comprehensive given tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It lists 'model_id, incidents (list of payload dicts, max 20)' but omits token and client_id. The Args block adds minimal meaning beyond schema field descriptions. Insufficient to make parameters fully understandable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Run RCA analysis over a batch of incidents using the same model' with specific verb and resource, and distinguishes from siblings like rca_analysis_run (single incident) and rca_analysis_compare.
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?
Description provides no guidance on when to use batch vs single analysis, no exclusions, and no mention of alternatives among the many sibling tools. The max incidents constraint (20) is mentioned but not framed as usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true. Description adds specific scope ('all its incident edges'), providing useful behavioral detail beyond the annotation. However, lacks info on reversibility, required permissions, or return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is concise and directly states the action. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema, description does not mention return values, error states, or prerequisites. With four parameters (three required) and a destructive action, the description is too brief to fully inform usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet description provides no explanation for any of the four parameters (name, token, graph_id, client_id). The description only mentions 'node' but does not map to the 'name' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action: 'Remove a node and all its incident edges from a causal graph.' Distinguishes from siblings like rca_graph_add_node (adds), rca_graph_delete (deletes entire graph), and rca_graph_remove_edge (removes edge only).
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 use this tool versus alternatives (e.g., rca_graph_delete, rca_graph_remove_edge). No mention of prerequisites (e.g., node must exist, graph must be editable).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing safety. The description adds the scoring formula and return format but does not disclose how root nodes are determined or any limitations. Contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence for purpose, one for formula, and two lines for Args/Returns. No unnecessary words. The formula is a valuable addition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite complexity (causal path ranking with a formula), the description omits prerequisites (e.g., graph must exist, node validity), the structure of ScoredPath return objects, and does not compensate for the lack of output schema details. Incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage per the context, and the tool description only lists the parameter names without adding meaning beyond the schema. The schema itself provides descriptions for top_k and target_node, so the description adds negligible value.
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 finds and ranks causal paths from root nodes to a target incident node, with a specific scoring formula. This distinguishes it from sibling tools like rca_graph_score (general scoring) and rca_graph_discover (discovery).
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 explicit guidance on when to use this tool versus alternatives like rca_analysis_explain or rca_analysis_query_results. Usage is implied but not clarified, leaving 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare the tool as read-only and idempotent. The description adds valuable context about specific checks performed (strategy availability, sklearn version, attribution compliance) and the return format. This goes beyond the annotations, though no side effects or error conditions are mentioned.
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 well-structured: a one-sentence summary, a bullet-like list of checks, and a clear specification of return format. Every sentence adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema available (not shown), the return format is described. However, the description lacks information on error cases, prerequisites (beyond the checks themselves), or how this fits into the larger workflow. It is adequate but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters (token required, client_id optional) with zero description coverage. The description does not explain these parameters at all, leaving the agent to guess their purpose. With low schema coverage, the description should compensate but fails completely.
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 validates PyRCA integration setup and reports active strategy. It includes a list of checks, making the purpose specific. However, it does not explicitly distinguish it from sibling tools beyond the context of PyRCA setup.
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 this tool should be used before running other PyRCA tools to verify setup, but it does not explicitly state when to use it vs alternatives or note any prerequisites. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's burden is lower. The description adds 'previously saved' implying it does not create new data. However, it does not disclose edge cases (e.g., missing result_id) or authentication requirements. This is adequate given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 8 words, highly concise, and front-loaded with the verb and object. Every word is necessary; no wasted text.
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 the existence of an output schema, the return format is covered. The tool has 3 parameters (token, client_id, result_id) and annotations cover safety. However, the description does not explain the token parameter's role or optional client_id, which are essential for correct use. It is barely adequate for a simple retrieval but missing key context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters. It only mentions 'result_id' implicitly in the phrase 'by result_id', but fails to describe 'token' (authentication) and 'client_id' (namespace). These omissions leave the agent unclear on required auth and optional scoping.
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 the clear verb 'Retrieve' with the resource 'previously saved RCA result' and specifies the identifier 'by result_id'. This clearly distinguishes from sibling tools like rca_analysis_list_results (list) and rca_analysis_query_results (query). 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 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 versus alternatives, no prerequisites (e.g., need a valid token), and no context on the expected state of the result_id. Without explicit when-to-use or when-not-to-use instructions, an agent may misuse this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context about format availability per plan (Starter+/Pro+), which is useful beyond annotations. No contradictions.
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. It includes a brief list of report contents and arguments. However, the emoji and plan marketing could be considered extraneous, slightly reducing clarity.
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 output schema exists, so return values are covered. But the description fails to mention the required 'token' parameter and does not provide a complete overview of all inputs. Given the tool's moderate complexity, the description is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. While it lists some parameters (session_id, format, include_guide_refs, custom_title), it omits the required 'token' and 'client_id'. The description does not clarify token's necessity or default behavior for client_id, leaving 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 tool's purpose: generating a maintenance/troubleshooting report from a completed diagnostic session. The verb 'generate' and resource 'report' are specific. However, it does not explicitly differentiate from siblings like rca_report_generate, missing explicit 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 usage after a completed diagnostic session, but lacks explicit guidance on when to use this tool versus alternatives (e.g., rca_report_generate). No preconditions or exclusions are provided, leaving it somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral trait that edges causing cycles are automatically rejected, and states the return type (JSON confirmation or cycle-detection error). Annotations declare readOnlyHint=false and destructiveHint=false, so the description adds context about cycle prevention. However, it fails to mention behavior on duplicate edges (e.g., replace, error) or the required token field for authentication, leaving gaps in understanding side effects.
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 extremely concise: two sentences plus a compact Args/Returns block. Every sentence contributes meaningful information (operation, constraint, parameter summary, return type). No fluff, no redundancy. It is front-loaded with the core action. Ideal length for quick comprehension.
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 that the tool has a nested parameter object with many properties, the description covers the main goal and constraint but lacks details on required parameters like token and optional ones like method. The output schema exists (though not shown), and the description states the return format partially. Missing clarity on authentication (token) and edge conflict resolution makes it moderately complete at best.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It lists the main parameters (graph_id, source, target, weight, confidence, method) and provides value ranges for weight and confidence [0,1]. However, it omits the required token parameter entirely and does not explain the meaning of method or client_id. The description adds some semantics but not enough for full understanding of all 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 clearly states the tool's purpose: 'Add a directed causal edge (source → target) to a graph.' It specifies the verb 'Add', the resource 'causal edge', the direction, and key constraint (DAG enforcement). This cleanly distinguishes it from sibling tools like rca_graph_add_node (adds nodes) and rca_graph_remove_edge (removes edges).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. While the DAG enforcement hint suggests it's for acyclic graphs, there is no comparative advice like 'use rca_graph_add_node to add nodes' or 'use rca_graph_remove_edge to remove edges'. This forces the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (only readOnlyHint=false). The description adds 'empty' but does not discuss idempotency, error states, or side effects beyond creation. With low annotation coverage, the description should provide more behavioral context.
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 concise (one line for purpose, then args/returns in a standard format). No filler, every sentence adds value.
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?
Output schema exists and is referenced. However, the description lacks critical context: authentication (token required from rca_auth_generate_token), what 'empty' means structurally, and preconditions. It meets basic needs but has gaps.
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 0%, so the description must compensate. It only mentions 'name' and 'description', omitting required 'token' (API key) and optional 'client_id'. The description adds no meaning beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create'), the resource ('new empty causal DAG for RCA'), and uses a specific verb. It distinguishes this from sibling graph manipulation tools (e.g., merge, delete) by emphasizing 'empty' and 'new'.
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 use this tool versus alternatives (e.g., merging, adding nodes). No prerequisite conditions (e.g., auth token must be generated first) or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by detailing the return structure (JSON with structural_score, coverage_score in [0,1]) and the metrics computed, enhancing transparency beyond annotations.
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 short and front-loaded, with a clear purpose statement followed by args/returns. It avoids redundancy, but could be more structured by explicitly listing parameters instead of a brief mention.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides output structure but omits details about prerequisites (e.g., graph must exist) and the token parameter's role. While annotations help, the tool is simple enough that this is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only mentions graph_id as an input, but does not explain token or client_id. The parameters are minimally documented, failing to compensate for the lack of schema 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 explicitly states the tool computes structural quality scores for a causal graph, listing specific metrics (density, DAG validity, etc.). It distinguishes from siblings like rca_graph_score_paths and rca_graph_markov_blanket, making the purpose clear.
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 guidance on when to use this tool versus alternatives such as rca_graph_score_paths or rca_analysis_* tools. The description lacks context on prerequisites or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds value by detailing the return content (plan details, limits, upgrades, upgrade URL), which goes beyond annotations. No contradictions.
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 brief with two sentences and a returns block, no wasted words. It is front-loaded with the core purpose. Slight improvement could be made by integrating the returns information more concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the plan name, limits, and upgrades. It does not mention permissions or errors, but for a read-only admin tool, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (token and client_id) with 0% description coverage. The description provides no explanation of these parameters, leaving the agent to guess their meaning or purpose.
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 shows the current plan name, feature limits, and upgrade options. It specifies the verb 'Show' and the resource 'plan info', and it distinguishes itself from sibling admin tools like health or audit log by focusing on plan details.
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 notes it is 'useful for understanding what features are available on your current plan,' implying when to use. However, it does not explicitly state when not to use or mention alternatives, leaving the guidance somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no further behavioral context (e.g., auth requirements, rate limits, prerequisites). It does not contradict annotations but fails to augment them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a compact Args/Returns block. It is front-loaded with the main purpose and contains no redundant information. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and presence of an output schema, the description adequately covers what the tool does. It mentions return content (narrative, causes, actions). Could mention prerequisite of a valid result_id, but not a major 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?
Input schema has 0% coverage at top level, but inner fields result_id and detail_level have descriptions. The description repeats these and adds the 'brief/standard/verbose' pattern but doesn't explain token or client_id. Schema coverage is low but description partly compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a structured explanation of an RCA result, specifying verb 'Generate' and resource 'RCA result explanation'. It mentions three detail levels, distinguishing it from siblings like rca_analysis_get_result (raw result) and rca_analysis_compare (comparison).
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 after having a result_id but provides no explicit guidance on when to use this tool vs alternatives like rca_analysis_get_result or rca_analysis_query_results. No when-not or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds format details and return type, but annotations already cover safety (readOnlyHint, idempotentHint). No additional behavioral context like authentication or rate limits.
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?
Short, front-loaded, single sentence plus bullet list. No redundant information, though some parameter info could be integrated more tightly.
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?
Covers core purpose and return value, but lacks explanation of token and client_id parameters. With low complexity, it's adequate but not thorough.
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?
Description explains graph_id and format (with enum values), but omits token and client_id. Schema description coverage is low, so description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'retrieve', resource 'causal graph', and supported formats (JSON, DOT, adjacency). Distinguishes well from sibling tools like create/delete.
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?
Does not explicitly state when to use or when not to use this tool versus alternatives, nor prerequisites like needing a valid graph_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the description correctly labels it as a non-read, non-destructive creation. However, it does not disclose additional behaviors such as authorization requirements, consequences of duplicate names, or rate limits, which would add value beyond the annotations.
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 structured with a family list, Args, and Returns sections. It is concise, using short lines and minimal redundancy. The only minor inefficiency is that the 'Args' line essentially repeats the schema's param name.
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 creation tool with complex nesting (ModelCreateInput), the description omits details like required fields apart from name and family, default values, validation rules, or error handling. It does not mention that the token is required. The output schema is noted as a JSON string with model_id, which suffices, but overall the description leaves knowledge gaps.
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?
Parameter schema coverage is 0%, so the description bears the burden. It lists ModelCreateInput fields (name, family, description, config, tags, version) and enumerates model families, but does not explain constraints like maxLength, required fields (token is not mentioned in description but is required in schema), or family-specific config expectations. This adds some meaning but is incomplete.
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 'Register a new RCA model spec in the registry.' It lists model families and differentiates from sibling tools like rca_model_list (list), rca_model_update_status (update), rca_model_validate (validate), rca_model_delete (delete), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a new model but does not explicitly state when to use it vs alternatives like rca_graph_create or rca_guide_ingest. No when-not-to-use or prerequisites are provided, leaving the agent to infer from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, indicating a write operation that is not destructive. The description adds that it adds a node, which is consistent. However, it does not disclose additional behaviors like duplication handling or validation of graph existence.
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 concise (two sentences plus an Args block) with no fluff. It front-loads the primary purpose and uses a standard Args/Returns format. 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 is simple with a clear input schema and an output schema. The description mentions the return type briefly. However, it does not specify prerequisites (e.g., that the graph must already exist) or potential side effects, leaving some gaps for a complete understanding.
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 provides rich detail (types, constraints, defaults). The description lists the parameters without adding new meaning beyond the schema, which has 0% coverage for parameter descriptions. The description repeats fields from the schema but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (add a typed node) and lists the allowed node types (metric, incident, symptom, root_cause, intermediate). This distinguishes it from sibling tools like rca_graph_remove_node and rca_graph_add_edge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding nodes to a graph but does not explicitly state when to use this tool versus alternatives (e.g., add_edge or remove_node). No when-not-to-use or prerequisite context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds 'List all...' which is consistent but provides no additional behavioral disclosure such as pagination or auth requirements beyond the schema's required 'token' parameter.
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-line description plus structured Args/Returns section. Purpose is front-loaded. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple filtered list tool, the description covers core behavior and return fields. However, missing explanation of auth parameters (token, client_id) slightly reduces completeness. Output schema exists to detail returns, compensating partially.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning description must compensate. Description mentions optional equipment_type and tags filters but omits explanation of required 'token' and default 'client_id' parameters. Only 2 of 4 parameters are addressed, adding minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List all ingested troubleshooting guides with optional equipment_type/tag filters', which is a specific verb+resource and distinguishes from siblings like rca_guide_search (search) and rca_guide_get (get specific guide).
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?
No explicit guidance on when to use this tool vs alternatives like rca_guide_search or rca_analysis_list_results. The description implies usage for listing with filters, but does not provide exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (no readOnlyHint, destructiveHint false), so the description carries the burden. It correctly describes the async behavior and immediate return of a task_id, but lacks details on queuing, cancellation, or potential side effects. No contradiction with annotations.
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 reasonably concise (three sentences) and front-loaded with the main purpose. The last line listing parameters is somewhat redundant with the schema, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple nature (submitting an async task) and the presence of an output schema, the description adequately covers the return value (JSON with task_id) and the polling mechanism. No major gaps for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists parameter names but provides no semantic information beyond what the schema already gives (schema coverage is partial). For instance, it does not explain required parameters like token or client_id, nor the expected values for model_id. The docstring only mentions 'model_id, payload, save, tags' without elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Submit a long-running RCA analysis') and the resource ('async background task'), and distinguishes it from synchronous runs and polling tools, with explicit reference to sibling tools rca_analysis_run and rca_analysis_poll_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (for long-running analyses) and directs the user to rca_analysis_poll_task for result retrieval. It does not explicitly state when not to use it, but the context with sibling tools implies the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=true, and the description adds that deletion is permanent and requires confirm=true. This additional context (permanence, safeguard) goes beyond what annotations already convey.
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, no redundancy. The verb 'delete' comes first, and the requirement 'confirm=true' is placed immediately. Every word adds value.
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 destructive tool with output schema (not described), the description covers key points (permanence, confirmation) but omits return value, idempotency implications, and differences from other delete tools. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions the 'confirm' parameter, ignoring 'token', 'model_id', and 'client_id'. No details on format, constraints, or how they affect 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?
The description clearly states the tool deletes a model permanently from registry and storage, using a specific verb and resource. It distinguishes itself from sibling tools like rca_model_create, rca_model_list, and rca_model_update_status.
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 deletion is destructive and requires confirmation but does not explicitly state when to use this tool versus alternatives (e.g., deactivating via rca_model_update_status). No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by disclosing that the tool sets the model status to 'validated' and computes specific metrics (coverage, mean_correlation, confidence). Annotations (readOnlyHint=false, destructiveHint=false) are consistent and provide an additional baseline. The description does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a clean args/returns block. It is front-loaded with the primary action and efficiently conveys purpose, computation, and side effect without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, side effects, and return format, but lacks context on prerequisites, error behavior, and integration with other model tools. For a validation tool with moderate complexity, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (though schema itself has some descriptions for two fields), and the tool description only lists parameter names in the args block without adding constraints, types, or explanations. The description does not compensate for the lack of schema 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 specifies the action (validate), resource (model), method (run quick validation on hold-out data), and outcomes (computes coverage/confidence metrics, sets status to validated). It clearly distinguishes from siblings like rca_model_update_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It mentions 'quick validation' but does not state prerequisites (e.g., model must exist) or when not to use it. Context signals and annotations do not compensate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to repeat these. It adds value by specifying the return format ('JSON comparison with consensus_causes and model_disagreements'), which provides insight into behavior beyond annotations. No contradiction.
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 extremely concise: one sentence for purpose, followed by clear Args and Returns annotations. No unnecessary words, and the most critical information is front-loaded. 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 the existence of output schema, the description appropriately says 'Returns: str: JSON comparison...'. It covers the main input constraint (2-10 result_ids) and purpose. However, it omits details on authentication (token) and optional client_id, and does not mention error handling or edge cases. Still, enough for a straightforward comparison tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the description does not explain individual parameters. The description mentions 'list of 2–10 result_ids' but does not clarify 'token' or 'client_id'. With 3 parameters fully defined in schema but only partially described, the description fails to add sufficient meaning 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 verb 'compare' and the resource 'multiple RCA results', and specifies outputs like 'overlapping root causes' and 'model disagreements'. This distinguishes it from siblings like rca_analysis_get_result (single result) and rca_report_compare (report comparison).
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 after RCAs have been run, but does not explicitly state when to use this tool versus alternatives. It could have mentioned prerequisites (e.g., 'use this after generating multiple RCA results with rca_analysis_run') or exclusions (e.g., 'not for comparing reports'). The input requirement of 2-10 result_ids is clear but no further guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveness (destructiveHint=true). Description adds that deletion is permanent and requires confirmation, going beyond annotations with explicit irreversibility.
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?
Exceptionally concise: two sentences, no filler, front-loaded with action and resource. Every word adds value.
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 delete tool with destructive annotations and output schema present, the description covers key behavioral aspects (permanent, requires confirm). Could mention what is destroyed but not strictly necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage per context, the description only addresses the confirm parameter ('Must be true to delete'), leaving token, graph_id, and client_id unexplained. Insufficient compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Delete a causal graph permanently' with a specific verb and resource, distinguishing it from sibling graph tools like create, get, or restore.
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?
Mentions the 'confirm=true' requirement, providing a precondition, but does not specify when to use this tool versus alternatives (e.g., restore_version) or any context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations aside from non-destructive hints, the description carries full burden. It discloses duplicate edge handling (keep higher weight), cycle handling (dropped and counted), and return format (JSON with counts). This is comprehensive but could further clarify whether original graphs are modified or if the operation is safe to repeat.
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 extremely concise and well-structured: a clear opening sentence defining the purpose, followed by bullet-point style Args and Returns sections. Every sentence adds value, and the most important information is front-loaded.
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 the tool's moderate complexity and the presence of an output schema (so return details are not required), the description covers merge behavior and conflict resolution. However, it lacks mention of required authentication (token), side effects on original graphs, and error conditions. These gaps reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists four key parameters (graph_id_a, graph_id_b, merged_name, conflict_resolution) and explains conflict_resolution values. However, it omits the required 'token' and optional 'client_id' parameters present in the schema. With 0% top-level schema description coverage, the description partially compensates but misses critical auth details.
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 'Merge' and the resource 'causal graphs', with a concrete example (combining network-layer and application-layer graphs). It distinguishes this tool from siblings like rca_graph_create or rca_graph_add_edge by specifying its cross-system graph merging role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for merging two distinct causal graphs (e.g., from different layers), but does not explicitly state when not to use this tool or provide alternatives. No mention of prerequisites or conditions where other tools like rca_graph_create would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true. Description adds 'Permanently delete' and 'requires confirm=true', clarifying destructiveness and approval step. Does not elaborate on side effects beyond deletion.
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?
Brief two-part description with emoji. Efficient but omits token parameter, which is a structural flaw. Otherwise well-organized.
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?
Covers action, role, confirm requirement, and return format. However, missing required token parameter and no output schema provided despite context claiming one exists. Gaps reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage per context; description lists only 'guide_id, confirm' but omits required 'token' parameter. Does not explain optional 'client_id' or add meaning beyond what minimal schema descriptions exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Permanently delete one of your own equipment guides' with specific verb and resource. Distinguishes from sibling tools like rca_guide_get, rca_guide_list, etc., as none are delete operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions admin role requirement and that 'confirm=true' is needed. Provides clear context for when to use but does not specify when not to use or offer alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, establishing safety. The description adds behavioral context by detailing the return JSON (task_id, status, progress, result, error), which helps the agent understand the lifecycle. It does not add conflicting or superfluous information.
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 very concise: two sentences front-loading the purpose and listing args/returns. There is no wasted text. However, it could be more structured by explicitly listing all parameters and their purposes while remaining 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?
For a simple polling tool, the description covers the async relationship, the expected output format, and error indication. With output schema and annotations filling safety/completeness, the description is largely sufficient. The main gap is incomplete parameter documentation, which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only mentions 'task_id' in the args, ignoring the required 'token' and optional 'client_id' parameters from the input schema. With schema description coverage at 0%, the description fails to compensate. The schema itself includes a description for task_id, but the tool description adds no new semantic guidance for the other 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 clearly states the tool 'Poll the status of an async RCA task' and specifies it is for tasks submitted via 'rca_analysis_run_async'. This provides a specific verb-resource combination and distinguishes it from sibling tools like synchronous analysis tools or result retrieval 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 implicitly guides usage by linking to rca_analysis_run_async as the task submission method, setting clear context. However, it does not explicitly state when not to use this tool or mention alternatives, such as rca_analysis_get_result for synchronous results. Given the clarity of the async polling use case, a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds context about immediate effect, ownership ('your own API keys'), and the return value (JSON confirmation). No contradictions with annotations.
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 well-structured: a clear opening statement followed by 'Args' and 'Returns' sections. It front-loads the purpose. The inclusion of parameter types and return type is helpful, though the 'Args' section largely duplicates schema 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?
The description covers the purpose, when-to-use, input parameters, and return value. For a destructive operation, it explicitly states 'immediately' and 'own API keys'. It lacks error scenarios or prerequisites, but the schema and annotations fill some gaps. The output schema exists, so the return description suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add any semantics beyond the input schema. It repeats parameter names but provides no additional explanation for 'client_id' or formatting guidance for 'token' and 'key_id_to_revoke'. The schema descriptions already cover these.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (deactivate), the resource (API key), and the context (immediate deactivation for compromised or retired keys). It distinguishes from sibling tools like rca_auth_generate_token and rca_auth_rotate_key by focusing on revocation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance ('useful when a key is compromised or an integration is being retired'). However, it does not mention when-not-to-use or suggest alternatives like rotation, though the context of immediate deactivation implies suitability for urgent scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, destructiveHint=false. The description adds that the tree is ingested as a json_dtree guide when save_as_guide=True, which is a side effect. It does not address authentication needs or error conditions, but the annotations cover safety, so the description adds meaningful context.
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 organized with a header, bullet-like Args and Returns, and an emoji. It includes a usage note about passing guide_id. It could be more concise, but the structure is clear and front-loaded.
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 core functionality, output format, and integration with rca_dtree_start. It assumes familiarity with FMEA analysis and result IDs. Given the existence of an output schema and sibling tools, it is fairly complete, though details on prerequisites (e.g., how to obtain fmea_result_id) are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists parameters (fmea_result_id, equipment_id, equipment_type, save_as_guide) but provides no explanation of their meaning or constraints. The input schema has descriptions for fmea_result_id and save_as_guide, but equipment_id and equipment_type lack descriptions. The tool description adds no semantic 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 it auto-generates a diagnostic decision tree from a completed FMEA analysis, converting HIGH-priority failure modes into a yes/no tree. It distinguishes from siblings like rca_dtree_start by specifying the input (FMEA result) and the output (guide_id for start).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: after completing an FMEA analysis, to generate a diagnostic tree. It also mentions the flow with save_as_guide and passing guide_id to rca_dtree_start. However, it does not explicitly state when not to use or compare to alternative methods like direct guide ingestion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark as read-only and idempotent. Description adds return format details ('JSON with metadata and sections'), which is useful behavioral context beyond annotations.
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?
Extremely concise: one sentence plus Args/Returns. No wasted words. Information is front-loaded with the purpose.
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 output schema exists and annotations are strong, description covers purpose, parameters, and return format adequately. Lacks examples or error handling, but sufficient for a simple read 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 0%, but description lists 'guide_id, optional section_id', clarifying their roles and that section_id allows fetching a specific section. Adds meaning beyond 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?
Description clearly states 'Retrieve a full troubleshooting guide or a specific section', specifying verb and resource. It distinguishes from sibling tools like rca_guide_search and rca_guide_list.
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 use this tool versus alternatives like rca_guide_search or rca_guide_list. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read-only, non-destructive write. The description adds behavioral context: auto-extraction of fault codes, plan limits, and indexing behavior. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a title, format details, plan limits, and an Args line. It front-loads the purpose. Some redundancy (e.g., repeating formats) could be trimmed, but overall efficient.
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 formats, auto-extraction, searchability, plan limits, and the return structure (guide_id, section_count, etc.). It lacks details on error handling or token requirements, but given output schema existence, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists parameter names (equipment_id, equipment_type, etc.) but adds no additional meaning beyond the schema. Schema description coverage is 0% (many fields lack descriptive text), so the description should compensate but fails to provide semantics for each parameter.
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 uploads and indexes an equipment troubleshooting guide. It specifies supported formats (markdown, plain, json_dtree) and notes auto-extraction of fault codes, distinguishing it from sibling tools like rca_guide_search.
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 mentions immediate searchability after ingestion and plan limits (Starter up to 10, Pro up to 100, Enterprise unlimited), giving context for when to use. However, it does not explicitly state when not to use or list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds the TF-IDF ranking method and the free plan result cap, providing useful behavior beyond the structured fields.
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 with a clear purpose sentence and organized Args/Returns sections. It is front-loaded and avoids unnecessary details, though the Args list could be more complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides return format details but omits the required 'token' parameter and does not differentiate from sibling search tools. Given the tool's many siblings and moderate complexity, it is adequate but has 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?
The description lists key parameters (symptom, equipment_type, tags, top_k) with numeric range (1-20), adding meaning beyond the schema. Although schema description coverage is reported as 0%, the description compensates by summarizing important params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches the equipment knowledge base by symptom using TF-IDF ranking, which distinguishes it from siblings like rca_guide_get or rca_guide_list. The verb 'search' and resource are 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 mentions the free plan cap (3 results) but does not provide guidance on when to use this tool versus alternatives like rca_guide_get or rca_analysis_query_results. Usage context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-only, idempotent, and non-destructive. The description adds algorithmic behavior (random walk, convergence) but does not disclose limitations, performance, or potential errors. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with purpose, algorithm, args, returns, and attribution. It is slightly verbose (duplicate attribution in first and last line) but overall efficient and front-loaded.
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 complex algorithm, the description covers inputs, algorithm, and output format. It lacks prerequisites (graph must exist) and interpretation details, but given the output schema exists, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains each parameter (adjacency, anomaly_scores, sli_metric, restart_prob) with clear semantics and context, adding significant value beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs graph-based root cause localisation using personalised PageRank random walk, specifying the mechanism (propagates backward, weighting by anomaly scores) and output (root cause probabilities). This distinguishes it from sibling tools like epsilon or HT diagnosis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but provides no explicit guidance on when to use it versus alternatives (e.g., epsilon diagnosis, HT diagnosis). It implies usage when a causal graph is available, but does not state prerequisites or compare methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the returned data (uptime, models/graphs, storage stats) and the return type (JSON string), providing context beyond the annotations.
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 extremely concise: one line for purpose and one for args/returns. Every sentence serves a clear purpose with no redundancy. It is well-structured and front-loaded.
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 health-check tool with an existing output schema, the description covers all essential aspects: what it returns (uptime, models, storage), required parameters (token, client_id), and return type. No gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description merely lists parameter names ('token, client_id') without adding meaning beyond the input schema. The schema already provides descriptions for both parameters, so the description adds no additional semantic value. Baseline of 3 is appropriate given 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 explicitly states the verb 'Return' and the resource 'server health status' including specific details like uptime, loaded models/graphs, and storage stats. This clearly distinguishes it from sibling tools like rca_admin_read_audit_log or rca_admin_purge_namespace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or contraindications. The context of checking server health is implied but not explicitly placed relative to other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals the iterative, state-mutating behavior (advancing the tree), which is consistent with annotations (readOnlyHint=false, destructiveHint=false). Adds value by describing the loop until resolved. No contradictions.
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?
Short and front-loaded with purpose. Includes Args and Returns sections for structure. The Returns list is somewhat verbose but informative. Overall efficient with no wasted sentences.
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?
Covers purpose, usage pattern, and return fields thoroughly. Lacks error handling details and explicit tie-in to session start tool, but is sufficient for a single-step tool in a multi-step workflow. Output schema exists but description provides a comprehensive return field list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description enumerates the main parameters (session_id, answer, measurement) but does not add significant detail beyond the input schema, which already has descriptions for these nested properties. Schema coverage is 0% for the top-level param, but the description provides a minimal mapping.
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 answers a diagnostic question to advance a decision tree, with a specific iterative usage pattern ('Call repeatedly until status == 'resolved''). It distinguishes from siblings like rca_dtree_start (initiates) and rca_dtree_list_sessions (lists).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call repeatedly until 'resolved', providing a clear usage pattern. Does not explicitly mention when not to use or alternatives, but the iterative context is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns the first question and expects subsequent answers via rca_dtree_answer, and outlines the return structure. However, it does not mention side effects (e.g., session creation), required authentication (token parameter), or any mutability assumptions beyond what annotations (all false) imply. Annotations are uninformative, so description partially carries the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (modes, args, returns) and uses emoji for quick scanning. It is front-loaded with the core purpose. Some redundancy exists (e.g., parameter list mirrors schema), but overall it is efficient and earns its 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?
Given the tool's complexity (two modes, nested parameters, interactive workflow) and the presence of an output schema (though not shown), the description covers essential aspects: purpose, modes, parameter roles, and return format. Minor gaps include missing details on token authentication and potential limitations (e.g., session expiration).
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 description adds meaning beyond the input schema by explaining the two modes and the relationship between guide_id and fmea_result_id. The schema itself contains property descriptions (e.g., token, symptom, client_id), but the description ties them together functionally. However, it does not elaborate on all parameters (e.g., equipment_id, symptom format).
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 that the tool begins an interactive diagnostic session using a decision tree guide. It specifies the resource (diagnostic session) and action (start), and distinguishes from siblings like rca_dtree_answer (which answers) and rca_dtree_list_sessions (which lists sessions) by focusing on session initiation.
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 explains two distinct modes (specific guide_id vs 'auto' from FMEA) and their prerequisites (e.g., fmea_result_id needed for auto mode). While it does not explicitly state when to avoid this tool or list alternative tools, the context for using each mode is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations lack behavioral hints (readOnlyHint=false etc.), so the description carries most transparency burden. It discloses the algorithm (PC-algorithm with partial correlation), constraints, and return format (JSON with graph_id and edge summary). It does not mention side effects like storage, but the algorithm description is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a single paragraph with bullet-like args and returns. It efficiently communicates the tool's purpose, inputs, and output without extraneous words. Minor improvement could be better separation of input details, but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (causal discovery), the description covers essential aspects: algorithm, data constraints, and output schema. It does not mention error handling or asynchronous behavior, but these may not be needed. The description is sufficiently complete for an agent to understand when 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?
The input schema already provides descriptions for 'data', 'name', and 'significance' parameters. The description summarizes them but adds minimal new information. With high schema coverage, the baseline is 3, and the description does not significantly enhance semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Automatically discover a causal skeleton from observational metric data using partial-correlation + Fisher-Z conditional independence tests (PC-algorithm).' It specifies the verb 'discover', resource 'causal skeleton', and methodology, distinguishing it from siblings like rca_graph_create (which likely creates graphs from existing structures).
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 the tool: for data-driven causal discovery from metrics. It includes constraints (min 30 rows, max 50 variables), guiding appropriate usage. However, it does not explicitly state when not to use or mention alternatives like rca_graph_create, which would improve differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true. The description adds that version history is preserved and that the restore creates a new snapshot, providing behavioral context beyond the annotation. It could mention potential permissions or undo mechanisms but suffices for most agents.
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 three sentences, front-loaded with purpose, and contains no fluff. Every sentence adds necessary information: purpose, behavioral note, requirement, and return format.
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 destructive nature and the existence of an output schema (described in return), the description covers the core behavior, confirm requirement, and return format. It omits explanation of token and client_id, which are standard across the suite, but remains largely complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description adds no parameter details. The schema itself provides descriptions for confirm, graph_id, and version_id, but not for token or client_id. The description fails to compensate for the low coverage, leaving agents to infer parameter usage from common patterns.
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 explicitly states 'Restore a causal graph to a specific historical version' and clarifies that it creates a new current state while preserving version history. This clearly distinguishes it from siblings like rca_graph_create, rca_graph_delete, and rca_graph_list_versions.
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 mentions the require confirm=true and notes that the operation itself is snapshotted, implying irreversibility. However, it does not explicitly guide when to use this tool versus alternatives, though the uniqueness of restore among siblings makes usage fairly obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that it lists all models and accepts optional filters, providing context beyond annotations.
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 concise Args/Returns. No fluff, essential info front-loaded.
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?
Simple tool with good annotations and clear return description. Could mention pagination or token requirement but adequate given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0%, but description only mentions family_filter and status_filter, ignoring the required token and optional client_id. Significant gap in parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'List' and resource 'registered RCA models', with optional filters specified. Distinct from sibling creation, update, delete, and validation 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?
Purpose is clear for listing models, but no explicit when-to-use or alternative exclusion. Context is well implied, so score 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate write operation (readOnlyHint=false) and not idempotent or destructive. The description adds context: execution triggers analysis, persists results if save=true, and returns JSON with root causes, confidence, explanation. It covers the expected behavior beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise summary sentence followed by details in docstring format (Args, Returns). It is front-loaded with purpose but could be slightly shorter without losing essential information.
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 the tool's complexity and the existence of sibling tools like rca_analysis_run_async, the description lacks mention of synchronous vs asynchronous execution, error handling, or performance implications. The output schema exists but description still covers returns adequately.
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 low (0% per context), but the description compensates by detailing the payload structure per model family, which is critical for correct usage. However, it omits optional parameters like token and client_id, which are 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 clearly states the tool executes RCA analysis using a registered model and returns ranked root causes. It explicitly states it is the primary analysis entry point, distinguishing it from sibling tools like rca_analysis_get_result and rca_analysis_batch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on what to supply (model_id and family-specific payload dict) and details payload structure per model family. It does not explicitly mention when not to use this tool or list alternative tools for specific scenarios, but labeling it as the primary entry point gives adequate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the annotations (readOnlyHint=true, destructiveHint=false) by disclosing that the tool 'Never returns raw or hashed key material' and that it requires admin role. Annotations already indicate safety; the description gives specifics.
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 concise with three sentences. It front-loads the main action and includes only essential information: what it does, security constraints, and return format. No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (list keys), the description is complete. It specifies the return type as a JSON string with fields (key_id, label, plan_at_issue, created_at, last_used_at, is_active), mentions requirements, and discloses what it does not return. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters: token (with description 'API key (admin role required)') and client_id (with description 'Client Id', default 'default'). The description does not add any additional meaning or clarify these parameters beyond what the schema provides. Schema description coverage is 0%, but the description fails 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 explicitly states the tool's purpose: 'List your own API keys and their metadata.' It uses a specific verb ('List') and resource ('API keys') and distinguishes itself from sibling tools like rca_auth_rotate_key and rca_auth_revoke_token.
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 the tool: 'Admin role required (Enterprise plan).' It implicitly suggests not to use it for key management tasks. While it does not explicitly name alternatives, the condition and the sibling tool list make the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the deactivation and replacement, aligning with the `destructiveHint: true` annotation and adding detail beyond it. No contradiction. It also specifies the admin role requirement, which is a behavioral constraint.
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 concise—three sentences plus structured Args/Returns. Every sentence adds value, and the purpose is front-loaded. No redundant or filler 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?
Given the tool's simplicity and the presence of an output schema, the description covers the main aspects: purpose, usage requirement, key parameter, and return format. It is largely sufficient, though more detail on parameters would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only explains the 'key_id' parameter in the Args section. The 'token' and 'client_id' parameters are not elaborated, despite having schema descriptions. Since schema description coverage is 0% (low), the description should compensate more for all 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 clearly states the tool deactivates an API key and generates a replacement for the same account. It specifies 'Admin role required (Enterprise plan)', making the purpose distinct from sibling tools like list or revoke keys.
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 indicates when to use (admin role, Enterprise plan) and mentions the required 'key_id'. It does not explicitly state when not to use or alternatives, but the sibling tool set implies context. Still, it is clear overall.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the tool's safety is well-covered. The description adds value by explaining the automatic version snapshot behavior and detailing the return format (JSON list of {version_id, created_at, node_count, edge_count}). No contradictions with annotations.
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?
Four lines, front-loaded with the purpose, followed by a brief explanation of version creation and the return format. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one required parameter (graph_id), the description is sufficiently complete. It explains the auto-snapshot behavior and explicitly lists the return fields. Annotations and output schema (implied by the return description) cover the rest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the input schema having a description for graph_id, the context signals indicate 0% schema description coverage, suggesting minimal parameter documentation in the schema. The tool description provides no additional meaning for parameters like token or client_id. Schema coverage is poor, and the description does not 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?
Description clearly states 'List all historical versions of a causal graph', providing a specific verb and resource. It effectively distinguishes from siblings like rca_graph_restore_version (which restores rather than lists) and rca_graph_get (which retrieves the current graph).
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?
Explains that versions are automatically snapshotted on save, which helps the agent understand when to use this tool. While it does not explicitly contrast with alternatives like rca_graph_restore_version, the context of version listing is clear. Implicit guidance is sufficient for this simple use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context by explaining the return structure (JSON with parents, children, co_parents, full_blanket) and the conceptual basis (d-separation). No contradictions.
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 very concise: 4 lines with a clear definition, conceptual explanation, and brief args/returns listing. Every sentence adds value, and the structure is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single node query, read-only, idempotent) and the existence of an output schema, the description provides adequate completeness. It explains the return format and the conceptual importance. Could mention handling of non-existent nodes, but this is 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 has 0% description coverage (only node has a brief description in schema). The description mentions graph_id and node in the Args line, adding some meaning for node (the node to compute). However, it does not explain token or client_id, which are required parameters. This partially compensates for the schema gap but not fully.
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 returns the Markov blanket of a node (parents, children, co-parents) and explains its significance. This distinguishes it from sibling graph tools like rca_graph_get or rca_graph_score, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it is 'essential for targeted RCA investigation,' providing clear context for when to use it. However, it does not explicitly state when not to use it or name alternative tools for similar tasks, so a slight gap remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by explaining the statistical rigor, descendant adjustment behavior, and the algorithm's purpose. No contradictions with annotations.
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 purpose, followed by recommendations, parameter details, return info, and attribution. Every sentence serves a purpose, but it is slightly verbose with academic references.
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 the complexity and presence of an output schema, the description covers the main functionality but lacks details on failure modes, edge cases (e.g., insufficient data), and error handling. Adequate but not exhaustive.
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?
Despite 0% schema description coverage, the description lists all key parameters with explanations (e.g., 'full time series', 'causal graph', 'p-value threshold default 0.05'). This adds meaning beyond the schema's structured descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs hypothesis-testing RCA with descendant adjustment (HT-ADJ). It specifies the verb 'tests whether the SLI anomaly can be statistically explained' and distinguishes itself from siblings by emphasizing statistical rigor and recommending it for well-validated causal graphs.
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?
Provides clear context: recommended when you have a well-validated causal graph and sufficient pre-anomaly data. This implies when not to use, but does not explicitly list alternatives or exclusions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, and description adds that the action is irreversible and requires confirm=true, going beyond annotations to clarify 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?
Description is extremely concise: three lines plus args/returns. Key information is front-loaded without any extraneous text.
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 admin tool with annotations and schema, the description covers all necessary aspects: what it deletes, the namespaces, the confirm requirement, and the return type.
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 for parameters is high (75% with descriptions), so description adds minimal extra meaning. The description lists the parameters but does not elaborate beyond 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?
Description clearly states it permanently deletes ALL records in a storage namespace, specifying the allowed namespaces (graphs/models/results). Distinguishes from sibling delete tools that target individual items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly requires confirm=true and emphasizes irreversibility, providing clear usage context. Does not explicitly mention alternatives but the purpose is clear enough for an admin tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal; description adds plan limits (Starter up to 10, Pro up to 100, Enterprise unlimited), max PDF size 50MB, and quality thresholds. It implies ingestion is a write operation but does not detail idempotency or conflict behavior. Overall, adds meaningful constraints beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: purpose, workflow, limits, and params. The args list is somewhat redundant with the schema but front-loaded with essential workflow. Each sentence serves a purpose.
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?
Includes recommended workflow, plan limits, max PDF size, and return fields (guide_id, section_count, etc.) despite lacking explicit output schema. Does not cover error handling or malformed input, but sufficient for typical 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?
The input schema has detailed descriptions for many parameters, so schema coverage is high. The description lists the parameter names but does not add new meaning beyond the schema. 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 'Parse a PDF equipment manual and ingest it into the RCA knowledge base' with a specific verb and resource. It distinguishes from siblings by recommending a workflow involving rca_guide_pdf_preview and rca_guide_search.
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 provides a recommended workflow: 1) preview, 2) ingest if quality >=0.5, 3) verify with search. Also includes plan limits and a skip_preview_check parameter, giving clear guidance on when and how to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant value beyond the annotations. Annotations indicate readOnlyHint and idempotentHint, and the description confirms this by stating it returns configuration without side effects. It also details the return format (JSON config dict with setup instructions) and lists supported providers, providing complete behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, a list of supported providers, and an args section. It is front-loaded and efficient, though slightly longer than necessary. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (one parameter with subfields) and presence of output schema, the description is mostly complete. It covers the main functionality and return value, but lacks detail on the 'token' and 'client_id' parameters, which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds partial value for the 'provider' parameter, listing possible values and behavior. However, it does not explain the 'token' (required) or 'client_id' parameters. The schema has 0% coverage, so the description should compensate, but it falls short for these two fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to get MCP client configuration and setup instructions for a specific provider or list all supported providers. It uses specific verbs and resources, and distinguishes itself from sibling tools, none of which share this objective.
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 tells when to use the tool (to get configuration for a listed provider) and how to use it (specify provider or omit to list all). It does not mention when not to use it or compare to alternatives, but given the unique purpose among siblings, this is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes fallback behavior for missing dependencies, format characteristics, and return structure, adding value beyond annotations (which only indicate non-destructive/non-readonly).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with bullet points for formats and sections; front-loaded with purpose. Slightly verbose but every sentence adds value.
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?
Covers inputs, outputs, optional features, and dependencies. Output schema is described implicitly; missing some edge-case details but adequate for the 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?
The input schema provides detailed descriptions for each parameter, and the tool description adds context about format requirements and output sections, compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates styled reports from RCA analysis results, lists supported formats, and distinguishes from sibling report tools like rca_report_compare.
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?
Provides guidance on when to use each format (e.g., 'good for GitHub/Slack/Notion' for markdown) and notes fallback behaviors, though it lacks explicit when-not-to-use comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing the algorithm (step-by-step), return format (JSON with specific fields), and the effect of the 'save' parameter. Annotations indicate readOnlyHint=false and destructiveHint=false, and the description confirms this is a compute operation with optional persistence, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (overview, algorithm, Args, Returns) and front-loads the purpose. While it is fairly long, every section adds value. It could be slightly more concise, but the structure aids readability.
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 algorithm, inputs, and output format comprehensively. However, it lacks explicit details on error handling, prerequisites (e.g., valid token, model existence), and internal dependencies like dispatch_rca(). Overall, it is sufficient for understanding the tool's core behavior.
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?
Although the input schema has 0% description coverage at the top level, the tool description summarizes the parameters (model_ids, payload, weights, save, token, client_id) and provides context for the EnsembleInput. This compensates well, but more detail on token and client_id would improve clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Run multiple RCA models on the same payload and combine root cause scores via weighted voting.' It specifies the verb (run/combine) and resource (RCA models and payload), distinguishing it from sibling tools like rca_analysis_run which likely runs a single model.
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 multiple models are available and want to ensemble results) but does not explicitly state when not to use it or name alternatives. The mention of weighted voting implies usage scenarios, but exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds that it does not load every full result record, and specifies the return format (JSON with total, results, has_more). No contradiction with annotations.
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 concise sentences followed by a brief args/returns list. Front-loaded with purpose and key differentiator. No wasted words.
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 moderate complexity, annotations cover safety, description covers filtering scope, efficiency, return format, and sibling comparison. Output schema exists (not shown) but return type is described. Complete for an indexed query 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 0% per context signals, but the description lists the key parameters (model_family, min_confidence, after_ts, tags, limit, offset) without further detail. It adds minimal value over the schema, but at least identifies the filtering capabilities.
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 queries stored RCA results with filters, and explicitly distinguishes it from the sibling rca_analysis_list_results by being more efficient for filtered lookups.
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 says it is more efficient for filtered lookups compared to rca_analysis_list_results, providing clear guidance on when to use this tool. It does not explicitly list when not to use, but the comparison implies context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the algorithm (z-score thresholding) and that it flags metrics with |z| > epsilon. Annotations already indicate read-only, idempotent, non-destructive. The description adds context about the distribution comparison without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise. It opens with a clear purpose, explains the algorithm, gives usage guidance, lists parameters, describes return value, and includes attribution. Every sentence adds value, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (statistical method with specific constraints) and the presence of annotations and input schema, the description covers all essentials: input requirements, algorithm, output format, and usage context. No gaps are evident.
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 description explains the key functional parameters (normal_data, anomaly_data, sli_metric, epsilon) with constraints (min 3 values per metric). It adds meaning beyond the schema by describing the role of SLI and the threshold's significance. However, it omits token and client_id, which are present in the schema but not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: identifying anomalous metrics contributing to an SLI anomaly using z-score thresholding. It distinguishes from siblings by specifying it's best as a first step before more compute-intensive causal methods, and uses a specific algorithm (epsilon diagnosis).
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 recommends use as a first step in RCA, implying when to use it. It does not list alternative tools explicitly, but the context of sibling tools and the mention of 'more compute-intensive causal methods' provides clear guidance. No exclusions are given, but it's clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the tool persists reports to storage ('save: persist to storage'), which adds transparency beyond annotations. Annotations have destructiveHint=false, consistent with saving. The return type (str) and content ('Comparative report with consensus_root_causes table') are disclosed. No contradictions found.
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 concise (around 5 lines) and well-structured: purpose statement first, then Args and Returns sections. Every sentence adds value without redundancy. Ideal for quick comprehension.
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 moderate complexity, the description covers the core purpose, all parameters with constraints, return type and content. The output schema exists (str) and the description explains the return value. Sufficient for an agent to use 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?
With 0% schema description coverage, the description compensates by briefly explaining each parameter: result_ids (2-10 result IDs), format (markdown|html), title (report title), save (persist to storage). This adds meaning beyond the schema's type and defaults, though more detail could be helpful.
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 generates a comparative report across 2-10 RCA results, highlighting consensus root causes, agreement percentages, and per-model summaries. This distinguishes it from siblings like rca_analysis_compare (comparison of analyses) and rca_report_generate (single report 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 specifies the range of result_ids (2-10) and lists all parameters, providing clear usage guidance. However, it does not explicitly mention when to use this tool over alternatives like rca_analysis_compare or rca_report_generate, missing explicit when-not or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool is safe and read-only. The description adds value by detailing the return JSON fields, which helps the agent understand what to expect, but does not introduce new behavioral traits.
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 concise and front-loaded with the key requirement (call before ingestion). It uses bullet points for strategies and clearly separates arguments and returns. Every sentence is necessary and informative without being verbose.
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?
The description covers purpose, usage guidelines, strategies, parameters, and return structure. It is well-aligned with the annotations and sibling tools, providing all necessary context for an agent to use the tool correctly. The absence of an output schema is compensated by the detailed return 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?
The description lists the parameters (pdf_base64, n_pages, strategy) and provides an example for encoding pdf_base64. While the input schema has descriptions for n_pages and strategy, the description adds context for the strategy options and a practical code example for pdf_base64, enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: preview a PDF before full ingestion to verify parsing quality. It explicitly distinguishes from the sibling tool rca_guide_ingest_pdf by advising to always call this first.
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?
Provides explicit usage guidelines: 'Always call this BEFORE rca_guide_ingest_pdf.' Also details strategy options (text_native, ocr, table, mixed, auto) with their appropriate use cases, giving the agent clear context on when to use each.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the key does not expire, cannot be recovered later, and that roles are for audit only. These go beyond the annotations (readOnlyHint=false, etc.) and provide necessary behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear lead sentence, usage instructions, plan details, and param breakdown. It is slightly verbose but earns its length with useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: purpose, usage, parameter details, return value (JSON with api_key), plan limitations, and security notes. The output schema is referenced, so return format is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains each parameter's purpose: roles are audit-only metadata, key_id is ignored, key_label is optional. This adds meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generate a new API key for authenticating all other tools' and specifies it issues the Free plan. This distinguishes it from sibling auth tools like rotate and revoke.
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 says 'Call this FIRST before using any other RCA-MCP tool' and provides instructions on storing the key and passing it as the 'token' field. Also clarifies that paid plans are handled separately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![rca-mcp-connector MCP server](https://glama.ai/mcp/servers/dave1362/rca-mcp-connector/badges/card.svg)](https://glama.ai/mcp/servers/dave1362/rca-mcp-connector)

Score Badge

Copy to your README.md:

[![rca-mcp-connector MCP server](https://glama.ai/mcp/servers/dave1362/rca-mcp-connector/badges/score.svg)](https://glama.ai/mcp/servers/dave1362/rca-mcp-connector)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dave1362/rca-mcp-connector'

If you have feedback or need assistance with the MCP directory API, please join our Discord server