get_score

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

With no annotations, the description carries the full burden. It discloses that the operation is static, safe (no network, no sandbox), and limited to SAFE and CLEAN axes. This is strong behavioral context for a read-only scoring tool, though it doesn't detail error behavior or computation specifics.

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 sentences, entirely purposeful. The first sentence states the core function and constraints; the second references the richer alternative. No filler or repetition.

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 tool is simple (one param, no output schema), and the description covers its purpose, scope, and limitations. It lacks details like whether local paths are accepted or what happens on error, but given the low complexity, it's adequately complete. The explicit sibling pointer further completes the context.

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 100% for the only parameter 'path', whose description already states '(required) Path to the repository to score'. The tool description adds no additional parameter meaning beyond pointing to 'repository', which matches the schema. Baseline 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 clearly states the tool computes a 'Fast static Umbra Trust Score (0-100) for a repository' with a specific scope ('SAFE and CLEAN axes only'). It explicitly differentiates itself from the sibling tool scan_repo by noting that scan_repo provides the full report. This is a specific verb+resource+scope.

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 explicit when-to-use guidance: 'Fast static... no network, no sandbox' implies quick local assessment. It also names the alternative: 'Use scan_repo for the full report with findings.' This clearly distinguishes from siblings and tells the agent which tool to choose.

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