Service agreements for freelancers: scope, deliverables, rate, termination and liability caps.
Scored across 9 tools
Each tool targets a distinct action: creating, reading, listing, rendering, checking, or changing status of an agreement, with clause and license tools clearly separated. Even render vs get are differentiated by purpose (presentation-ready output vs full data read).
Core tools consistently use the 'agreement_' prefix with a clear action suffix, and all names are snake_case. Minor deviations exist with 'clause_library' and 'license_activate'/'license_status', which break the noun_verb pattern but remain predictable.
Nine tools is well-scoped for a service agreement server: six agreement operations, one clause library, and two license tools. Each tool earns its place without redundancy or bloat.
The core lifecycle is covered: create, read, list, render, and status transitions through draft/sent/signed/expired. The main gap is the lack of an update/delete tool for editing agreement content, though expiring a finished agreement partially addresses freeing slots.
The before-you-send-it checklist for one agreement: every missing field is listed, and terms whose absence cuts one way are flagged neutrally -- as written, what the gap means for both parties -- such as no termination clause or an uncapped liability. Reads only.
| Name | Required | Description | Default |
|---|---|---|---|
| agreement | Yes | The agreement id, e.g. SA-2026-0003, or the client name when only one agreement has it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Reads only,' which is critical behavioral transparency given no annotations are provided. It also discloses the neutral, non-judgmental framing of flagged terms ('as written, what the gap means for both parties'), which helps the agent understand the tool's output tone and scope. It doesn't detail output format, but the read-only disclosure carries significant weight.
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 zero waste. The core purpose is front-loaded ('before-you-send-it checklist'), and the second sentence adds valuable detail about flagging behavior without redundancy.
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 read-only tool with 100% schema coverage, the description is nearly complete. It explains what the tool does, its read-only nature, and the neutral framing of flagged terms. The only minor gap is not describing the exact output structure, but with no output schema and a simple checklist concept, the description is sufficient for an agent to select and invoke the 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?
Schema coverage is 100%, so the schema already documents the single parameter. The description adds context by implying the parameter is an agreement identifier, but it doesn't add meaning beyond the schema's example and explanation. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('check'), a specific resource ('one agreement'), and a clear scope ('before-you-send-it checklist'). It distinguishes itself from siblings like agreement_get and agreement_list by focusing on missing fields and gap analysis, not just retrieval or listing.
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 clearly implies when to use this tool: before sending an agreement, to review missing fields and flagged terms. It doesn't explicitly name alternatives or exclusions, but the 'before-you-send-it' framing and the focus on missing fields provide clear context that separates it from agreement_get (retrieval) and agreement_render (formatting).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a service agreement between a freelancer and a client before the work starts: the parties, the scope of services, the deliverables, the rate and payment terms, start and end dates, a termination notice period, a liability cap and the governing jurisdiction. Stores the agreement and returns it rendered as clean Markdown with a signature block. Free tier: 3 active agreements; expiring a finished one frees its slot.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| scope | Yes | The services the freelancer provides, e.g. Design and build of a five-page marketing site, with two weeks of post-launch fixes | |
| client | Yes | Who the work is for, e.g. Brightleaf Studio | |
| clauses | No | Ids of library clauses to include, from clause_library: ip_assignment, confidentiality, late_payment, kill_fee, revision_rounds. The clause library is a Pro feature | |
| currency | Yes | ISO code the rate and cap are in | |
| end_date | No | The date the engagement ends, YYYY-MM-DD. Leave unset for an open-ended engagement | |
| rate_unit | Yes | What the rate buys: an hour, a day, or the whole project | |
| freelancer | Yes | Who does the work, e.g. Anna Nowak, or Nowak Design | |
| rate_cents | Yes | The rate in whole cents. 8500 is 85.00 | |
| start_date | No | The date work begins, YYYY-MM-DD. May be in the future; it is a plan, not a log | |
| deliverables | Yes | What the client receives at the end, e.g. ["Five-page site deployed to the client's host", "Handover document"] | |
| jurisdiction | No | The governing law and courts, e.g. England and Wales, or the State of New York | |
| payment_terms | Yes | When and how it is paid, e.g. Net 14 from invoice date, or 50% on signing and 50% on delivery | |
| client_address | No | ||
| freelancer_address | No | ||
| liability_cap_cents | No | The most the freelancer can be liable for, in whole cents. Leave unset and liability is uncapped, which the checklist flags | |
| termination_notice_days | No | Days of written notice either party must give to end the agreement, e.g. 14 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the tool stores the agreement and returns it rendered as Markdown with a signature block, and mentions the free-tier quota with a release mechanism. It does not cover error handling or validation, but the main side effects are clear.
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 concise sentences, no filler. The purpose is front-loaded, the content list is compact, and the output/quota info is tacked on efficiently. 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 tool with 17 parameters, no output schema, and no annotations, the description covers the main purpose, the output format, and a key quota constraint. It does not detail all parameters, but the schema does. The omission of error conditions and interaction with siblings like agreement_checklist is a minor gap, but overall the description is adequate 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?
Schema description coverage is 82%, so the schema already documents most parameters. The description adds a high-level summary of what the agreement includes, but does not clarify format or constraints beyond what the schema provides. This meets the baseline for high coverage without adding significant value.
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's function: writing a service agreement between freelancer and client. It enumerates the key sections (parties, scope, deliverables, rate, payment terms, dates, termination, liability, jurisdiction) and distinguishes itself from siblings by noting it stores the agreement and returns rendered Markdown. This is specific and 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 ('before the work starts') and a constraint (free tier: 3 active agreements), which tells an agent when this tool is appropriate. It doesn't explicitly name alternatives like agreement_update_status for modifications, but the create-vs-update distinction is implied by the verb and the sibling list. A clear when-not-to-use statement would elevate this to 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one service agreement in full by SA number or client name: parties, scope, deliverables, rate and payment terms, dates, termination, liability cap, jurisdiction, the clauses it carries, its status and its status history. Reads only.
| Name | Required | Description | Default |
|---|---|---|---|
| agreement | Yes | The agreement id, e.g. SA-2026-0003, or the client name when only one agreement has it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and does well: 'Reads only' explicitly signals a non-mutating, safe operation, and the field enumeration tells the agent what to expect in the result. It does not cover failure modes or permissions, but those are less critical for a simple read.
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?
One front-loaded sentence states the action and identifier options before listing the returned content, with no filler. The long enumeration is justified because there is no output schema to carry that 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 one-parameter read tool with no output schema, the description covers both how to identify the agreement and what will be returned. The client-name uniqueness constraint lives only in the schema, but the schema is available to the agent, so the definition is complete enough.
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%, so baseline 3 applies. The description repeats the identifier options from the schema but omits the caveat that client name works 'when only one agreement has it'; it adds no new parameter meaning.
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 — 'Read one service agreement in full' — then enumerates the contained fields and closes with 'Reads only,' which distinguishes it from create/update siblings. The title and description align, and the tool's scope is 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 description gives clear context: use this when you need the full detail of one agreement selected by SA number or client name. It does not explicitly name alternatives or state when not to use it, so it stops just 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.
List 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It adds ordering behavior ('newest first'), a business rule ('active until expired'), and a quota constraint ('free tier holds 3 active agreements'), which go beyond the schema. It does not mention pagination or explicitly state read-only, but listing inherently implies read-only and the added constraints are valuable.
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 three concise sentences: the main action and ordering are front-loaded, followed by returned fields and filters, then a relevant business rule. There is no waste; 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 two optional filters, the description covers purpose, ordering, returned fields, filters, and a business constraint. The only minor gap is pagination or result limits, which are not mentioned, but for this tool the provided context is largely sufficient.
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%, with both client and status already described with their semantics. The description only echoes 'Filter by status and by client' without adding new meaning. Since the schema already provides parameter details, the description adds no extra value beyond confirmation.
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 and resource ('List service agreements'), specifies ordering ('newest first'), enumerates the returned fields (parties, status, rate, dates, clauses), and lists the two filters. This clearly distinguishes it from siblings like agreement_get (single retrieval) and agreement_create (creation).
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 makes the listing intent obvious and mentions the filtering options, but it does not explicitly contrast with alternatives like agreement_get or state when not to use it. The 'list' verb and filter semantics imply a browse scenario, but no direct sibling differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a service agreement ready to send and sign: the parties, the services, the deliverables, the payment terms, the term, termination, liability, jurisdiction, any library clauses it carries, and a signature block for both parties. Markdown, or self-contained HTML with print CSS that needs nothing from the network. HTML is a Pro feature. Writes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | markdown (default) or html. The HTML carries its own styling and references nothing external. HTML is a Pro feature | |
| agreement | Yes | The agreement id, e.g. SA-2026-0003, or the client name when only one agreement has it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It explicitly states 'Writes nothing' (read-only), discloses that HTML is self-contained and a Pro feature, and lists what the rendered output contains. Minor gap: it doesn't explicitly state the return format (e.g., string) or error behavior, but the format is implied by the format parameter.
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 with no wasted words. The core purpose is front-loaded, followed by a compact enumeration of document contents and a clear format constraint. 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 two-parameter tool with no output schema, the description covers purpose, contents, format, and side effects. It could explicitly state that the output is a document string and how missing agreements are handled, but these are minor omissions. Overall sufficient for correct invocation.
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 both parameters fully. The description adds only the Pro feature note for HTML and the self-containment detail, which duplicates the schema description. It provides no substantive additional meaning 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 (render) and resource (service agreement), and enumerates the exact sections included, making its function unmistakable. It clearly differentiates from siblings by the action – rendering a document for signing, not creating, retrieving, or updating status.
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 conveys a clear context: rendering a document ready to send and sign, and mentions format options (markdown vs html). However, it does not explicitly contrast with alternatives like agreement_get (which returns raw data) or agreement_update_status, so exclusions are left implicit rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move one agreement exactly one step: draft, sent, signed, expired, stamping the date and an optional note into its history. A skipped or backwards step is refused and nothing is written. Expiring a finished engagement frees a free-tier slot.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | The date to stamp the step with, YYYY-MM-DD. Default today | |
| note | No | ||
| status | Yes | The next step for this agreement: draft, sent, signed, expired | |
| agreement | Yes | The agreement id, e.g. SA-2026-0003, or the client name when only one agreement has it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: the step must be exactly one forward move, invalid steps are refused atomically (nothing is written), and expiring a finished engagement frees a free-tier slot. It does not mention authentication, rate limits, or error handling, but the disclosed behaviors are substantive and go beyond the bare action.
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, front-loaded with the core action and immediate constraints. Every clause carries meaning: the step sequence, the refusal rule, and the free-tier side effect. No filler or redundancy.
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 has 4 parameters, no output schema, and no annotations. The description covers the step logic and side effects but omits return value on success, potential errors (e.g., nonexistent agreement), and prerequisites. For a state-changing tool, this is a moderate gap; an agent might not know what to expect after a successful call.
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 75% (3 of 4 params described). The description adds meaning to the 'note' parameter (calls it optional) and reinforces the 'status' constraint (must be the next step). It does not repeat schema details but does add context for the undocumented note parameter, partially compensating for the 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 states a specific verb ('Move') and a precise resource ('one agreement exactly one step') with the allowed states enumerated. It clearly distinguishes this from siblings like agreement_create or agreement_get by defining the action as a single forward step in a status sequence, with explicit refusal of invalid moves.
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 when to use this tool—when advancing an agreement's status—and even states constraints like 'a skipped or backwards step is refused.' However, it does not name alternative tools or explicitly say 'use this instead of X.' The guidance is present but implicit, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the built-in clause library: intellectual property assignment, mutual confidentiality, late payment interest, kill fee and revision rounds. Each clause is a title plus a body text. Pass an agreement and, on Pro, every body comes back with that agreement's variables filled in. The free tier lists titles and summaries; the full texts are a Pro feature.
| Name | Required | Description | Default |
|---|---|---|---|
| agreement | No | Fill each clause body with this agreement's variables. Pro feature |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does well by disclosing the return shape (title plus body text), the variable-substitution behavior with an agreement, and the free-tier limitation (titles and summaries only). It stops short of a 5 because it omits details such as error behavior or what happens without an agreement.
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 front-load the action and resource, then cover optional-parameter behavior and tier restrictions without wasted words. The enumerated example clauses are useful context, not padding.
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 there is no output schema, the description appropriately explains what the tool returns and the fields involved. It covers variable substitution and tier limits well. It could be slightly more explicit about the default behavior when no agreement is passed, but the optional-parameter phrasing and free-tier note make this reasonably inferable.
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 'agreement' parameter already has a schema description that says 'Fill each clause body with this agreement's variables. Pro feature.' The tool description essentially restates this, adding no new semantic meaning. Since schema coverage is 100%, 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 uses a specific verb ('List') with a concrete resource ('built-in clause library') and enumerates its contents, including the clause categories and the title/body structure. This makes it clearly distinct from the sibling agreement_* and license_* tools, which operate on agreement or license records rather than the static clause catalog.
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 clear context for using the tool: pass an agreement to fill clause bodies with that agreement's variables, and notes the Pro/free tier difference. It does not explicitly name alternatives or state when not to use the tool, but the intended usage is unambiguous enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn Pro on for this connection with key, an MCPL1.. issued at checkout for this server or the bundle. Data under your token stays; a wrong or expired key changes nothing. license_status confirms it.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | License key from checkout, MCPL1.<payload>.<signature> |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states that data under the token stays and that a wrong or expired key changes nothing, which is valuable non-destructive and failure-mode context for an activation mutation.
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 tight sentences front-load the action and key requirement, then add side-effect guarantees and a pointer to verification. No wasted words or repetition beyond the schema format.
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 activation tool with no output schema and no annotations, the description covers the action, key eligibility, non-destructive behavior, failure mode, and how to confirm success. It could add explicit return-value expectations, but license_status confirms it largely covers that 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 schema already fully documents the key parameter, so the baseline is 3. The description adds meaningful semantics by explaining the key must be issued at checkout for this server or bundle and that invalid keys are no-ops, going beyond the schema's simple format 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 uses a specific action, 'Turn Pro on for this connection,' with a clear resource (license/Pro status) and key format. It also distinguishes itself from the sibling license_status by focusing on activation rather than checking status.
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 conveys when to use the tool: when activating Pro with a checkout-issued key for this server or bundle. It also references license_status as the follow-up confirmation step, though it stops short of explicitly saying 'use license_status instead to check current status.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report this endpoint's licence state for your token as JSON: the product, the tier free or pro, why it is not Pro, and the checkout URL. Call it to explain a free-tier refusal. No arguments, nothing changes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states 'No arguments, nothing changes,' indicating a read-only, side-effect-free operation. It does not detail error handling or authentication requirements, which are minor omissions for a simple status check, but the core behavioral trait (no mutation) is clearly communicated.
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, tightly packed with all essential information. It is front-loaded with the primary action and output, then adds the use case and side-effect note. Every sentence earns its place with no redundancy or fluff.
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 tool with no input parameters and no output schema, the description fully covers what an agent needs: the return format (JSON with product, tier, reason, checkout URL), the trigger condition, and the lack of side effects. Nothing essential is missing.
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 tool has zero parameters, and the description confirms 'No arguments.' Per the scoring rules, 0 parameters earns a baseline of 4. The description adds no parameter-specific meaning because none exist, and it correctly reiterates the absence of arguments, aligning with the empty 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 and resource: 'Report this endpoint's licence state for your token as JSON'. It explicitly enumerates the returned fields (product, tier, reason, checkout URL), making the tool's purpose unambiguous. It also distinguishes itself from sibling tools like license_activate by focusing on status reporting rather than activation.
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 a clear trigger for use: 'Call it to explain a free-tier refusal.' This tells the agent when to invoke this tool. It does not explicitly discuss alternatives or exclusions, but the purpose is distinct enough from siblings that the guidance is adequate; it could be improved by noting it is the only read-only license info tool, though that is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
agreement_checklistagreement_createagreement_getagreement_listagreement_renderagreement_update_statusclause_librarylicense_activatelicense_statusContract drafting, statute-cited US state law requirements, non-compete checks, risk analysis.
Freelance business manager — clients, proposals, invoices, time tracking, scope, and follow-ups.
Compliant invoicing for freelancers: create, issue and track invoices from your AI agent.
Fixed-fee software consultancy. Ask about scope, terms, and live capacity.
Add one secure layer between your agents and this server.
