A supplier directory that does not rot: contacts, terms, lead times, review dates.
Scored across 10 tools
Each tool targets a distinct resource or action: license lifecycle, supplier CRUD, review workflow, and export are cleanly separated. Even supplier_get vs supplier_list are clearly differentiated by cardinality, and supplier_update explicitly excludes the review stamp to avoid overlap with supplier_mark_reviewed.
Tool names follow a consistent supplier_<verb> pattern with a parallel license_<action> group. Minor deviations are supplier_due_review, which is a noun phrase, and license_status, which uses a noun rather than a verb, but the overall convention is uniform and predictable.
10 tools is well-scoped for a supplier directory server covering license management, full CRUD, review workflow, and export. Each tool earns its place with no redundant surface area.
The tool surface covers the full lifecycle: add, get, list, update, remove, plus review stamping and due-review reporting. License activation and status handle tier gating, and export provides an output path, so there are no obvious dead ends.
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.
Add a supplier to the directory and return its SUP-YYYY-NNNN number: the name, what they supply, who to contact and how, the payment terms, the lead time in days, and notes. Free tier: 10 suppliers; removing one you no longer use frees its slot.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Who you buy from, e.g. Shenzhen Box Co, or Acme Fasteners | |
| No | Orders or accounts email | ||
| notes | No | Anything worth remembering: minimum orders, who to escalate to, why you dropped them last time | |
| phone | No | Phone number as you would dial it | |
| address | No | Postal or visiting address | |
| website | No | Website or storefront URL | |
| category | Yes | What they supply, e.g. Packaging, Raw materials, Print. Free-form; supplier_list filters on it | |
| contact_name | No | Your person there, e.g. Maria Chen | |
| payment_terms | No | The terms you buy on, e.g. Net 30, 50% upfront, Due on receipt | |
| lead_time_days | No | Typical days from order to delivery, e.g. 14 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the capacity limit (10 suppliers, removal frees a slot) and the return format. However, it does not mention failure modes, idempotency, validation behavior, or side effects beyond creation. It is partial disclosure for a mutation tool.
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: the first states purpose and fields, the second gives the free tier constraint. No filler, front-loaded with the core action and return value.
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 description covers the essential context for calling the tool: what it does, what it returns, and a key capacity constraint. It does not mention error handling or explicitly note that only name and category are required, but the schema provides that. For a 10-parameter creation tool, it is reasonably complete.
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 the baseline is 3. The tool description summarizes the fields (name, supply, contact, payment terms, lead time, notes) but adds little beyond the schema's individual parameter descriptions. It groups them conceptually but does not provide new semantic detail.
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 ('Add a supplier'), the resource (directory), and the expected output (SUP-YYYY-NNNN number). It enumerates the fields captured, distinguishing it from siblings like supplier_update or supplier_remove without ambiguity.
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 does not explicitly guide when to use this tool versus alternatives (e.g., 'use this for new suppliers, not existing ones'). It mentions the free tier limit and freeing slots, which is context but not direct routing. The purpose implies creation, but no explicit exclusions or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The due-review report: every supplier whose record has not been reviewed in the last N days -- 90 unless you say otherwise -- most overdue first. A record never reviewed is always due, whatever its age. This is the report that keeps the directory from rotting. Pro feature.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | A record is due when its last review is older than this many days. Default 90 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the sorting behavior (most overdue first), the default threshold, and the special rule for never-reviewed records. However, it does not disclose whether this is a read-only operation, whether it requires any special permissions, or what the output format looks like. The 'Pro feature' note hints at access restrictions but is vague.
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 concise and front-loaded: it states the core purpose in the first sentence, then adds the default behavior, sorting, and edge case rule. The 'Pro feature' note is a minor extra but not wasteful. 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 report tool with one optional parameter and no output schema, the description covers the key behavioral aspects: default threshold, sorting, and the never-reviewed edge case. It doesn't describe the output format, but with no output schema, that might be a minor gap. The 'Pro feature' hint is vague but not critical. Overall, it's fairly complete for its complexity.
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 the schema already documents the 'days' parameter well. The description adds the default value (90) and the semantic meaning of the parameter (a record is due when last review is older than this many days), which aligns with the schema. It doesn't add much beyond the schema, but the default value is useful context. 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's purpose: it generates a report of suppliers whose records have not been reviewed within a specified number of days, sorted by most overdue first. It uses a specific verb ('due-review report') and resource ('supplier records'), and distinguishes itself from sibling tools like supplier_list or supplier_get by focusing on review staleness.
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 the default behavior (90 days unless specified) and the rule that never-reviewed records are always due. It implies when to use this tool (when you need to identify stale supplier records for review), but it does not explicitly state when not to use it or mention alternatives like supplier_list for general listing. This is clear context but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the supplier directory as CSV or a Markdown table: every field, one row per supplier, A to Z by name. CSV opens in any spreadsheet; Markdown drops into a doc, a wiki or a README. Filter by category and free text first if you only want part of it. CSV is free; Markdown is Pro.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Only suppliers whose fields contain this text, case-insensitive | |
| format | No | csv (default) or markdown | |
| category | No | Only suppliers in exactly this category, case-insensitive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It clearly explains output shape (full directory, one row per supplier, sorted A-Z), format consumption (spreadsheet vs doc/wiki/README), and the Pro/free gating on Markdown. It does not mention rate limits or auth, but it covers the essential behavior of the export.
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, each earning its place: scope and formats, consumer-friendly explanation, filtering guidance, and licensing condition. The core action is front-loaded with no redundant wording.
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?
There is no output schema, so the description must explain what the caller gets back. It does: complete fields, row granularity, sort order, both formats, filtering behavior, and a licensing caveat. For a simple export tool this is complete enough to call 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 input schema already documents all three parameters with 100% coverage, so the baseline is 3. The description adds modest context by mentioning filtering by category and free text, and by noting the CSV/Markdown output difference, but it does not add significant 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 names a specific verb ('Export'), a specific resource ('the supplier directory'), and the exact output forms ('CSV or a Markdown table'). It further characterizes scope ('every field, one row per supplier, A to Z by name'), which clearly distinguishes it from related tools like supplier_list or supplier_get.
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 usage context: filter by category and free text if you only want part of the directory, and notes that Markdown output requires Pro while CSV is free. It does not explicitly name sibling alternatives to avoid, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one supplier record in full by SUP number or name: every contact field, the payment terms, the lead time, the notes, and when the record was last reviewed. Reads only.
| Name | Required | Description | Default |
|---|---|---|---|
| supplier | Yes | The supplier id, e.g. SUP-2026-0003, or the name when only one supplier has it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It explicitly states 'Reads only.' (read-only) and specifies the returned content, which gives an agent a clear picture of side effects (none) and response scope. It also discloses the lookup method (by SUP number or name), adding transparency beyond the title.
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 that front-load the action and return scope, with no filler. 'Reads only.' is an efficient safety signal.
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 one-parameter read with no output schema, the description covers the input (SUP or name), the returned field set, and the read-only nature. Its only omission, behavior for ambiguous names, is already handled by the schema description, so nothing an agent needs 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 schema already describes the supplier parameter at 100% coverage, so the baseline is 3. The description's phrase 'by SUP number or name' restates the schema's id/name disambiguation without adding new constraints, formats, or detailed semantics. Therefore it adds no meaningful parameter information 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 clear verb and resource ('Read one supplier record in full') and enumerates the content scope (contact fields, payment terms, lead time, notes, last reviewed). This differentiates it from sibling tools like supplier_list (reads many) or supplier_update (mutates). Title reinforces the single-record read.
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 usage for retrieving a complete single supplier record by identifier, and the 'Reads only.' line signals it is not for updates. However, it does not explicitly name alternatives such as supplier_list or supplier_due_review or state conditions for when not to use it, leaving some inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the supplier directory A to Z by name: contact, payment terms, lead time, when each record was last reviewed and how many days ago that was. Filter by category and by free text across every field. Reads only.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Only suppliers whose name, category, contact, terms or notes contain this text, case-insensitive | |
| category | No | Only suppliers in exactly this category, case-insensitive |
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 so well: it explicitly states 'Reads only' to signal safety, discloses the sort order (A–Z by name), and lists every returned field including the recency metric. No hidden side effects are implied.
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: the first names the output plus ordering, the second names the filters and read-only nature. Everything earns its place and key facts are 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?
For a read-only list tool with no output schema, the description covers the returned fields, sort order, filtering behavior, and safety profile. Nothing an agent needs to make the call correctly 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?
Schema coverage is 100%, and the schema already documents q and category precisely, including case-insensitivity. The description's 'Filter by category and by free text across every field' only summarizes those parameters rather than adding new meaning, so it earns the baseline.
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—'List the supplier directory'—and spells out exactly what is returned: contact, payment terms, lead time, and review recency. It is unambiguous about being a list/read operation, so it cannot be confused with supplier_add, supplier_update, or supplier_get.
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 establishes clear use context: use when you need the supplier directory A–Z, optionally filtered by category or free text. It does not name alternatives or state when not to use it, but 'Reads only' plus the list framing makes the appropriate situation evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stamp a supplier's record as reviewed on a date, today by default: you have checked the contact, the terms and the lead time are still true. This is the stamp supplier_due_review reads, so a reviewed record stops being flagged as stale.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | The date you reviewed the record, YYYY-MM-DD. Default today | |
| supplier | Yes | The supplier id, e.g. SUP-2026-0003, or the name when only one supplier has it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that this is a state-changing stamp, defaults to today, and that it is the exact marker supplier_due_review reads so the record is no longer flagged stale. It could mention overwrite/idempotency behavior, but the core side effect is 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?
Two tightly written sentences with no filler. The core action and default date come first, and the second sentence justifies the tool's role in the review workflow, earning 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 two-parameter mutation with a fully documented schema, the description covers purpose, when to use it, and downstream effect. It omits explicit return-value information, but no output schema exists and the behavioral context is otherwise 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 description coverage is 100%, so the parameters are already fully documented. The description adds no new parameter-level detail beyond restating the default-today behavior already in 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 uses a specific verb ('Stamp') with a clear resource ('a supplier's record') and the exact state change ('as reviewed on a date'). It distinguishes this from sibling tools like supplier_update and supplier_due_review by framing it as the action that clears the stale flag.
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 conditions for use: after checking contact, terms, and lead time are still true. It also explains the downstream effect on supplier_due_review, making the intended workflow clear, though it does not explicitly list 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.
Remove a supplier from the directory by SUP number or name, returning the record as it stood so nothing is lost silently. The SUP number is never reissued. On the free tier the slot is freed for another supplier.
| Name | Required | Description | Default |
|---|---|---|---|
| supplier | Yes | The supplier id, e.g. SUP-2026-0003, or the name when only one supplier has it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses that the record is returned as it stood (so nothing is lost silently), that the SUP number is never reissued (implying permanence), and the free-tier slot behavior. It does not explicitly warn about irreversibility beyond that, but covers key behavioral aspects.
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 and then adds important behavioral details. Every sentence adds value.
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 destructive tool with no output schema or annotations, the description covers purpose, lookup methods, return behavior, and policy implications. It does not mention error handling or idempotency, but for this low complexity it 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?
The schema already provides a clear description of the 'supplier' parameter, including example format and uniqueness condition. The description adds a redundant phrase ('by SUP number or name') but does not add significant new meaning beyond the schema. Baseline 3 is appropriate given 100% schema coverage.
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 ('Remove a supplier from the directory') and the resource (supplier), and specifies the two lookup methods (SUP number or name). It distinguishes itself from sibling tools like supplier_get or supplier_update by the explicit removal action and the return of the prior record.
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 this tool is for removing a supplier, but it does not explicitly state when to use it versus alternatives or when not to use it. It provides context about the free tier and SUP reissuance but lacks direct comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change any of a supplier's fields by SUP number or name: name, category, the contact fields, payment terms, lead time, notes. Only the fields you pass change; pass at least one. The SUP number and the review stamp are not writable here -- supplier_mark_reviewed does the stamp.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Rename the supplier | |
| No | Orders or accounts email | ||
| notes | No | Anything worth remembering: minimum orders, who to escalate to, why you dropped them last time | |
| phone | No | Phone number as you would dial it | |
| address | No | Postal or visiting address | |
| website | No | Website or storefront URL | |
| category | No | What they supply, e.g. Packaging, Raw materials, Print. Free-form; supplier_list filters on it | |
| supplier | Yes | The supplier id, e.g. SUP-2026-0003, or the name when only one supplier has it | |
| contact_name | No | Your person there, e.g. Maria Chen | |
| payment_terms | No | The terms you buy on, e.g. Net 30, 50% upfront, Due on receipt | |
| lead_time_days | No | Typical days from order to delivery, e.g. 14 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses that updates are partial, that at least one field must be passed, and that the SUP number and review stamp are not writable here. It does not describe failure behavior or return value, but the central mutation semantics are transparent.
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 tight sentences front-load the action and then add only the essential behavioral caveats. Every sentence earns its place, and the description is easy to scan.
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 11 parameters, all fully documented in the schema, and no output schema or annotations, the description covers the important operational context: partial updates, at-least-one requirement, and non-writable fields. It leaves minor gaps such as return value and not-found behavior, but the tool remains callable correctly from this definition.
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% and each parameter already has a detailed description, so the baseline is 3. The description adds meaning beyond the schema by explaining the partial-update contract, requiring at least one field, and clarifying that the supplier identifier can be a SUP number or name and that the SUP/stamp fields are excluded.
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: 'Change any of a supplier's fields', then enumerates the field groups. It clearly distinguishes itself from siblings like supplier_add, supplier_remove, supplier_get, and supplier_mark_reviewed by stating what this tool updates and what it does 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?
It gives clear partial-update usage guidance: 'Only the fields you pass change; pass at least one.' It also names an explicit alternative for the excluded review-stamp behavior: 'supplier_mark_reviewed does the stamp.' It does not explicitly contrast with supplier_add or supplier_get, so it stops short of full when/when-not coverage.
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.
license_activatelicense_statussupplier_addsupplier_due_reviewsupplier_exportsupplier_getsupplier_listsupplier_mark_reviewedsupplier_removesupplier_updateVendor document & expiry tracking for septic operators — read-only live demo board tools.
Electronic component sourcing, BOM management, and PCB design workflows.
AEC subcontractor vendor procurement plumbing layer. Preview - V3 launches 2027.
Add one secure layer between your agents and this server.
