bridge_centrality

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

No annotations are provided, so the description carries the full burden. It discloses that it computes a score with a specific formula, persists results to a 'centrality_scores' table, and returns a markdown table. It also notes the persistence side-effect. This is more than minimal, though it doesn't cover auth requirements or error conditions. No contradictions with annotations (none exist).

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 well-structured: it states the purpose, explains the formula, mentions persistence, and lists params. It is dense but each sentence earns its place. The param documentation is at the end, which is conventional. No waste; it could be slightly trimmed but is appropriately sized for a tool with a formula and side effects.

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?

Given the tool has an output schema (not shown in the prompt, but indicated as present), the description covers the return type ('Markdown-formatted ranking table'). It also explains the persistence and downstream use. It lacks edge-case handling or error scenarios, but for a centrality computation tool, the description is sufficiently complete for an agent to use it correctly.

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?

The schema has no descriptions (0% coverage), but the description provides explicit parameter docs: ':param top: Number of top connectivity modules to return (default 20)' and ':param include_imports: Whether to include IMPORTS in connectivity (default True).' This adds meaning beyond the schema's types and defaults, fully compensating for the schema 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 clearly states a specific verb and resource: 'Compute module connectivity: how many unique modules each module interacts with.' It then explains the score formula and the use case, and explicitly contrasts with betweenness centrality, which differentiates it from sibling tools like 'centrality'. 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.

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

The description provides context on when to use it: 'For well-modularized codebases, identifies orchestrator and hub modules' and explicitly states it replaces betweenness centrality in cases where inter-module edges are zero. It also mentions integration with 'framework_nodes()'. However, it doesn't explicitly list alternative tools or when not to use it beyond the betweenness contrast, so it's clear but not exhaustive.

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