Identify all strongly connected components in a directed graph using Kosaraju's two-pass algorithm, enabling cycle and dependency analysis from vertices and directed edges.
Find all strongly connected components in a directed graph using Kosaraju's two-pass algorithm.
| Name | Required | Description | Default |
|---|---|---|---|
| edges | Yes | Directed edges as [from, to] pairs | |
| vertices | Yes | Number of vertices (0-indexed) |
Changes observed during successful MCP inspections.
v0.1.11Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It mentions the two-pass Kosaraju algorithm but does not describe the return format, ordering of components, input assumptions beyond what the schema states, or any performance characteristics. This is a significant gap for an algorithmic tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that contains no filler. It efficiently communicates the action, the graph type, and the algorithm used.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The input schema is fully documented, but there is no output schema and the description does not explain the return value's structure, such as whether components are lists of vertex IDs or how they are ordered. For an algorithmic tool with no annotations, this leaves the agent with a minimum viable but incomplete understanding of the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented: vertices is the number of 0-indexed vertices and edges is an array of [from, to] pairs. The description adds no further parameter semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: find all strongly connected components in a directed graph. It also names Kosaraju's two-pass algorithm, which distinguishes it from sibling SCC tools such as tarjan_scc and gabow_scc. An agent can identify what the tool does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over alternatives like tarjan_scc or gabow_scc. It only says what algorithm is used, not when that choice is preferable. The usage is implied by the tool name and description, but no explicit context 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.