service-contract

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description reinforces this with 'Reads only.' It adds substantive behavioral context by specifying that missing fields are listed and one-sided gaps are flagged neutrally with implications for both parties. No contradiction exists.

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 compact, front-loads the key phrase 'before-you-send-it checklist,' and then elaborates with useful examples. The middle clause is slightly dense, but every part contributes meaning and there is no wasted content.

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 one-parameter, read-only tool with no output schema, the description conveys the main deliverable and gives concrete examples of what the checklist surfaces. It does not specify the exact response format or whether a summary verdict is returned, but the tool's low complexity makes this a minor gap.

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 single required parameter is fully described in the schema (agreement id or client name, maxLength 200), and schema description coverage is 100%. The description does not add parameter-level detail, but the baseline of 3 applies because the schema already carries the burden.

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 defines a specific deliverable: a pre-send checklist for one agreement, listing every missing field and neutrally flagging one-sided gaps such as no termination clause or uncapped liability. This clearly distinguishes it from siblings like agreement_get (retrieval), agreement_render (document generation), and agreement_update_status (state change).

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 phrase 'before-you-send-it checklist' gives a clear trigger: use this when preparing to send an agreement. It does not explicitly name alternative tools or state when not to use it, but the read-only analytic purpose is unambiguous from context.

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

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

It goes beyond the all-false annotations by disclosing that the tool persists the agreement ('Stores the agreement'), returns a rendered Markdown artifact with a signature block, and has a free-tier quota of 3 active agreements with expiration freeing a slot. This gives an agent the side-effect, output, and constraint context annotations alone don't provide. No contradiction with readOnlyHint=false.

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 sentences, each earning its place: purpose/fields, storage/output, quota behavior. It is front-loaded with the core action and avoids restating schema details.

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?

Even without an output schema, it tells the agent what to expect (clean Markdown with signature block) and that creation is persistent and quota-limited. The rich schema covers the remaining parameter semantics, so nothing essential is missing for calling this tool.

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 82% and the schema already describes each field, including formats and examples. The description groups the fields semantically (parties, scope, deliverables, rate, dates, etc.) but adds no new parameter-level meaning, so the baseline 3 applies.

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 first sentence names the action ('Write'), the object ('a service agreement between a freelancer and a client'), and the timing ('before the work starts'). It also lists the substantive fields and notes that it stores and renders Markdown, which cleanly separates it from read/status sibling tools.

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 clearly situates use at the pre-work stage ('before the work starts'), which is a meaningful trigger condition. It does not explicitly name sibling alternatives such as agreement_get/list or agreement_update_status for the opposite cases, though the creation semantics make those exclusions inferable.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description's 'Reads only' repeats the read-only hint but adds no further behavioral context such as authentication needs, error behavior, or ambiguity handling.

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 one tight, front-loaded sentence that states the core action first, then uses a colon-separated list to define what 'in full' includes. There is no filler or unnecessary 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?

With no output schema, the description compensates by enumerating the returned content: parties, scope, deliverables, payment terms, dates, termination, liability cap, jurisdiction, clauses, status, and status history. It is sufficient for a simple one-parameter read tool, though it does not cover edge cases like not-found or ambiguous client names.

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 already describes the single parameter well, including the SA-2026-0003 example and the client-name caveat, so schema coverage is 100%. The description echoes 'by SA number or client name' but does not add meaningful detail beyond the schema.

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 a specific verb ('Read'), a resource ('one service agreement in full'), and the lookup methods (SA number or client name). It is clear and informative, though it does not explicitly contrast with sibling tools like agreement_list or agreement_render, so it stops short of a full 5.

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 implies the tool is for retrieving a single complete agreement when you have an SA number or client name. It does not explicitly state when to use this tool instead of siblings such as agreement_list or agreement_render, nor does it give any exclusions.

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

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.

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

The description states 'Writes nothing,' but the annotations set readOnlyHint=false, which directly contradicts the claim: a tool that writes nothing is read-only. This is a serious inconsistency that undermines the agent's trust in both the description and the annotation. No additional behavioral context is provided beyond the format note.

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?

Four short sentences with the core purpose front-loaded. The long list of agreement sections is useful content, not fluff, and each sentence carries distinct information. Slightly dense list at the start but still efficient.

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?

No output schema exists, and the description does not explicitly state what the rendered output looks like (e.g., returned as a string, file, or URL), though the Markdown/HTML format choice implies it. The read-only contradiction also muddies side-effect understanding. Adequate for a simple two-parameter tool, but the missing return semantics and the contradiction leave 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 description coverage is 100% for both parameters: `format` already documents markdown/html and the Pro feature, while `agreement` already explains the id or client-name syntax. The description adds no parameter-specific meaning beyond this, so the baseline 3 applies.

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 a specific verb and resource ('Render a service agreement') and enumerates the exact sections included, clearly distinguishing this from sibling tools that create, list, check, or update agreements. An agent can immediately tell what this tool does and what it is not.

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 phrase 'ready to send and sign' gives clear context for when to use the tool, and the Pro-feature note for HTML adds a practical constraint. It does not explicitly name alternatives or specify when NOT to use it, so it stops short of a 5.

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

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

Annotations indicate a non-read-only, non-destructive mutation. The description adds valuable behavioral details: refusal of skipped/backward steps with no write, stamping of date/note into history, and the side effect of freeing a free-tier slot when expiring a finished engagement. This goes beyond the annotations without contradicting them.

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 two sentences with no filler. It front-loads the core action, then adds crucial constraints and side effects. Every sentence earns its place.

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 mutation tool with no output schema, the description covers the main behavior (one-step transitions, refusal conditions, side effect) and integrates with the annotations. It does not mention return values or error handling, but these are minor for this operation. Overall, an agent has enough to call 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?

Schema description coverage is 75% (date, status, agreement have descriptions; note does not). The description does not add parameter-specific details beyond what the schema already provides. It reinforces that status must move sequentially, but that is behavioral, not parameter semantics. 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 action (move one agreement one step), the specific sequence of statuses (draft, sent, signed, expired), and distinguishes it from other agreement tools by focusing on status transition. The title reinforces this, making the purpose unmistakable.

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 intended use is implied by the description (transition an agreement through its lifecycle), but it does not explicitly state when to use this tool versus alternatives like agreement_create or agreement_get. No exclusions or alternative routing are mentioned, leaving the agent to infer from context.

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

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

The description discloses tier-dependent behavior (free vs Pro), what each clause contains (title plus body), and the variable-filling behavior when an agreement is passed. Annotations are all false, so the description carries the burden and does a good job explaining the read-like behavior despite no readOnlyHint.

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 compact and front-loaded with the core purpose, then adds tier details. It's slightly dense with the Pro/free distinction but every sentence earns its place.

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 list tool with one optional parameter and no output schema, the description covers the main behaviors: what's listed, the structure of each clause, and the tier differences. It doesn't specify the exact output format, but that's less critical for a list operation.

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%, so the schema already documents the agreement parameter. The description adds meaningful context by explaining that the parameter is a Pro feature and that it fills variables into clause bodies, which goes beyond the schema's description.

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 lists the built-in clause library and enumerates the specific clause types (intellectual property assignment, mutual confidentiality, late payment interest, kill fee, revision rounds). It distinguishes this from agreement-focused siblings by specifying it's about the clause library, not agreements themselves.

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 explains when to pass an agreement (to get variables filled in on Pro) and notes the free tier limitation. It doesn't explicitly name alternatives or say when not to use this tool, but the context is clear enough for an agent to decide when this tool is appropriate.

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

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

Annotations already indicate this is not read-only and not destructive, and the description adds useful behavioral detail: existing data under the token stays, and a wrong or expired key changes nothing. This goes beyond the annotation hints by explaining failure semantics and safety of the operation.

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 two sentences with no filler. It front-loads the core action, then gives the key format and safety guarantees, and closes with the verification tool. Every sentence contributes essential information.

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 single-parameter activation tool with annotations covering the safety profile, the description is complete: it states what the tool does, what input is needed, what happens on failure, and how to confirm success. There is no missing critical information for an agent to call 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 already documents the key parameter and its format with 100% coverage. The description adds meaning by specifying that the key must be issued at checkout for this server or the bundle, which clarifies validity requirements not present in the schema.

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 uses a specific verb and resource: it 'turns Pro on' for the connection using a license key. It also distinguishes itself from the sibling license_status tool by saying license_status confirms the activation. This leaves no ambiguity about what the tool accomplishes.

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 for use: the key must be an MCPL1.<payload>.<signature> issued at checkout for this server or the bundle. It does not explicitly list exclusions or alternative tools, but it does reference license_status as the confirmation path, giving the agent a sense of the workflow.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context beyond annotations by specifying the JSON response contents and stating 'nothing changes,' reinforcing the read-only nature of the call.

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 dense sentences cover output, purpose, usage context, and side-effect guarantee. Every sentence earns its place and the most important information is front-loaded.

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?

With no output schema, the description sufficiently describes the return value. With no parameters, annotations covering safety, and a clear use case, nothing essential is missing for an agent to invoke this tool 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?

There are zero parameters and the schema already fully documents that fact. The description explicitly says 'No arguments,' which is accurate and reinforces the schema without needing further elaboration.

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 begins with a specific verb ('Report') and a precise resource ('this endpoint's licence state for your token'), and enumerates the exact output fields: product, tier, reason, and checkout URL. This clearly distinguishes it from sibling tools like license_activate.

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 explicitly states when to call it: 'Call it to explain a free-tier refusal.' This is clear contextual guidance, though it does not name alternatives or explicitly state when not to use it.

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