agreement_listList service agreements newest first: parties, status, rate, dates and the clauses each carries. Filter by status and by client. An agreement is active until it is expired; the free tier holds 3 active agreements.
| Name | Required | Description | Default |
|---|---|---|---|
| client | No | Only agreements whose client contains this text, case-insensitive | |
| status | No | Only agreements at this status: draft, sent, signed, expired |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already supply readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds genuinely useful behavior beyond those: ordering ('newest first'), domain semantics around active/expired status, and the free-tier cap of 3 active agreements – all of which affect an agent's expectations and decisions.
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?
Three short sentences, front-loaded with the action and scope, followed by filter options and a domain constraint. Every sentence earns its place, and the structure makes the most important facts immediately visible.
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?
For a simple read-only list tool with two optional, fully documented parameters and no output schema, the description covers the returned fields, ordering, and a key business rule (free-tier cap). It lacks explicit pagination or scoping notes, but those are not essential given the tool's simplicity.
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 input schema already documents both parameters fully (100% coverage) with descriptions for client (case-insensitive contains) and status (allowed values). The description only restates the filters without adding new detail, so it meets the baseline but does not elevate it.
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 opens with 'List service agreements newest first' – a specific verb, resource, and ordering – then enumerates the returned fields (parties, status, rate, dates, clauses) and filter dimensions. This clearly distinguishes it from siblings like agreement_get, agreement_render, and agreement_update_status without needing to open schemas.
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 clear context: it lists agreements newest first and can be filtered by status and client, which is enough for an agent to know when to call it. It does not explicitly name alternatives or state when not to use it, but the context is unambiguous and no exclusion guidance is needed for such a straightforward list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.