Ranks people by modules they solely hold or that would be orphaned if they leave, exposing single points of failure and who an organization cannot afford to lose.
People ranked by what leaves with them: modules that would be orphaned and modules where they are the sole holder. Use for 'who can we not afford to lose', 'single points of failure'.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| tenant | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose the ranking logic (orphaned modules and sole-holder modules), which is useful beyond structured data. It stops short of describing permissions, output format, or how tenant scoping affects results.
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?
Two short sentences, front-loaded with the core ranking definition followed immediately by usage triggers. No filler or redundant restatement of the name.
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 conceptual framing is complete enough to know what the tool computes, but with no output schema, no annotations, and two undocumented parameters, the agent lacks detail on result shape and parameter effects. Adequate but with clear gaps.
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 coverage is 0% and the description is silent on both 'limit' and 'tenant'. The names plus defaults make them partly guessable, but the description does not define what tenant does or what unit limit controls, so it fails to compensate for the coverage gap.
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 names the resource (people) and the ranking criterion (orphaned modules, sole-holder modules), which is a specific analytical output rather than a restatement of the name 'keystones'. It distinguishes itself conceptually from siblings like what_if_leaves or successors, though it never explicitly names them.
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?
It supplies concrete use-case triggers ('who can we not afford to lose', 'single points of failure'), which tells the agent when this tool fits. However it gives no exclusions or contrast with the very similar what_if_leaves sibling, so the agent must infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.