Conecto

Add or change a supplier

purchasing_save_supplier

Idempotent

Add a supplier, matched by name (any case), or change one by supplier_id (name then renames it): contact name, email (purchase orders are emailed there), phone, address, tax ID, the currency they bill in (default: the books' or the invoice profile's), payment terms in days (their bills fall due that long after their date; default 30), and account: the book account code their bills' lines go to by default (an expense or asset account, e.g. "6600"). iban and bic are where the business pays them: new or changed bank details always wait for a person other than the one asking (approval_required), because a changed account is how invoice fraud takes payments. Give only what changes. Archived suppliers take no new orders or bills. Costs $0.01 per call; nothing if it fails.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "purchasing_save_supplier"
  }
}

Input Schema

Name	Required	Description
`bic`	No
`iban`	No	Their IBAN; spaces are fine.
`name`	No
`email`	No
`notes`	No
`phone`	No
`tax_id`	No
`account`	No	A book account code, e.g. "6600"; "" clears it.
`address`	No	Postal address, one line per row.
`country`	No	Where they are, ISO 3166-1 like "FR": tells reverse-charge bills apart.
`archived`	No
`currency`	No	ISO 4217, e.g. "EUR".
`terms_days`	No
`supplier_id`	No
`contact_name`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 28, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations, it discloses the IBAN/BIC approval gate (a second person must approve, with the fraud rationale), the per-call cost and failed-call exemption, the archived-supplier restriction, and defaults for currency and payment terms. These are operationally decisive facts an agent cannot infer from the schema or hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and create/update routing are front-loaded, and nearly every clause adds real information. However, it is one dense run-on paragraph with long nested parentheticals, which makes the approval rule and cost note harder to scan than they should be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-parameter, zero-required upsert with no output schema, the description covers creation, update, defaults, approval, and cost. It never says what the call returns (e.g. the supplier_id or, when bank details trigger review, whether the change is pending), which is the one gap an agent must know before chaining calls.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 33% schema description coverage across 15 parameters, the description carries the burden well: it explains email's role in PO delivery, account as a book account code with clearing semantics, currency and terms_days defaults and due-date behavior, and iban/bic as the payment destination subject to approval. Only notes and the archived flag remain thin, and country/address are already covered in-schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first clause states a precise verb and resource and immediately disambiguates the two modes: create by name (case-insensitive match) versus update by supplier_id. It also clarifies the rename side effect ('name then renames it'), so an agent knows exactly what the call does against the sibling supplier tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear operating conditions: supply name to add, supplier_id to change, 'Give only what changes' for partial updates, and archived suppliers accept no new orders or bills. It doesn't name competing siblings such as purchasing_list_suppliers or purchasing_save_supplier_items, so a lookup-vs-write routing decision is left implicit.

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

All Conecto tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?