get-uirs

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Get' which implies a read operation, but doesn't specify whether this retrieves all UI requirement documents, a specific subset, or how they're returned (format, structure, pagination). No information about permissions, rate limits, or error conditions is provided. The description is minimal and leaves critical behavioral aspects unspecified.

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, straightforward sentence that efficiently states the tool's purpose. There's no wasted verbiage or unnecessary elaboration. However, it could be more front-loaded with additional context about what 'User Interface Requirement Documents' specifically entail in this system.

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 no annotations, no output schema, and the description provides minimal context, this is incomplete for effective use. The agent knows what to retrieve but not what format it returns, how many documents, what fields they contain, or any behavioral constraints. For a document retrieval tool with zero structured metadata, the description should provide more operational 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?

The description provides no parameter information, but the input schema has 100% description coverage with a clear explanation of the 'cwd' parameter. Since schema_description_coverage is high (>80%), the baseline score of 3 is appropriate. The description doesn't add any value beyond what the schema already documents about parameters.

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 'Get User Interface Requirement Documents for this project' which provides a clear verb ('Get') and resource ('User Interface Requirement Documents'), but it doesn't differentiate from sibling tools like 'get-bps' (presumably business process documents) or 'get-brds' (presumably business requirement documents). The purpose is understandable but lacks specificity about what distinguishes UI requirements from other requirement types.

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 no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate versus other 'get-' tools for different document types, nor does it specify any prerequisites or constraints beyond the implied project context. The agent must infer usage from tool names alone.

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