Skip to main content
Glama

qonto_create_quote

RÉSERVÉ AU STUDIO (token). Crée un devis client Qonto (D-2026-XXX) et renvoie numéro, total, lien client, id. Client cherché par id, email puis nom ; création possible avec create_client_if_missing=true + adresse (jamais inventée : address_unknown=true pose des tirets). Anti-doublon : refuse un devis identique le même jour (sauf force=true) ; request_id rend l'appel rejouable sans doublon. Aucun PDF dans la réponse : prepare_quote_email (qonto_type=quote, qonto_number=D-…) l'envoie, qonto_get donne l'URL PDF. En cas de doute sur l'état : qonto_list avant de relancer.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNoVille — obligatoire pour créer un client.
forceNoCréer même si un document identique (même client, même total, même jour) existe déjà. Défaut false.
itemsYesLignes (au moins 1).
zip_codeNoCode postal — obligatoire pour créer un client, sauf address_unknown.
client_idNoId Qonto du client (prioritaire sur email/nom).
auth_tokenNo
request_idNoIdentifiant unique de CET appel (ex. 'mate027-devis-2026-09-22'). Si le même request_id est rejoué (timeout, relance), le serveur renvoie la réponse d'origine sans rien recréer.
tin_numberNoSIREN/SIRET (ou n° fiscal étranger) du client : rend le type company possible. Optionnel.
vat_numberNoN° TVA intracom du client créé (optionnel).
client_kindNoType du client créé. Défaut individual (le nom du label/artiste est conservé tel quel comme nom affiché) ; company UNIQUEMENT avec tin_number (SIREN/SIRET) — sinon Qonto refuse le devis.
client_nameNoNom du client (label, studio, artiste ou 'Prénom Nom'). Recherche exacte insensible à la casse.
client_emailNoEmail du client (recherche par email d'abord).
contact_nameNoPrénom Nom de la personne de contact (ex. 'Rafa Santos') quand client_name est un label — sert de prénom/nom Qonto. Optionnel.
validity_daysNoJours de validité du devis (défaut 30).
client_countryNoCode pays ISO2 du client créé (défaut FR).
street_addressNoAdresse de facturation (rue) — obligatoire pour créer un client, sauf address_unknown.
address_unknownNoLe client n'a PAS communiqué son adresse : rue/code postal remplacés par « — » (ville + pays requis). JAMAIS inventer une adresse — la demander au client.
create_client_if_missingNoSi le client n'existe pas : le créer (sinon erreur explicite). Exige alors l'adresse ci-dessous.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed19 schema fields changed
    • addedInput schema / properties / address_unknown
      Added value: +{
      +  "description": "Le client n'a PAS communiqué son adresse : rue/code postal remplacés par « — » (ville + pays requis). JAMAIS inventer une adresse — la demander au client.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / city
      Added value: +{
      +  "description": "Ville — obligatoire pour créer un client.",
      +  "type": "string"
      +}
    • addedInput schema / properties / client_country / description
      Added value: +"Code pays ISO2 du client créé (défaut FR)."
    • addedInput schema / properties / client_email / description
      Added value: +"Email du client (recherche par email d'abord)."
    • addedInput schema / properties / client_id
      Added value: +{
      +  "description": "Id Qonto du client (prioritaire sur email/nom).",
      +  "type": "string"
      +}
    • addedInput schema / properties / client_kind
      Added value: +{
      +  "description": "Type du client créé. Défaut individual (le nom du label/artiste est conservé tel quel comme nom affiché) ; company UNIQUEMENT avec tin_number (SIREN/SIRET) — sinon Qonto refuse le devis.",
      +  "enum": [
      +    "company",
      +    "individual"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / client_name / description
      Added value: +"Nom du client (label, studio, artiste ou 'Prénom Nom'). Recherche exacte insensible à la casse."
    • addedInput schema / properties / contact_name
      Added value: +{
      +  "description": "Prénom Nom de la personne de contact (ex. 'Rafa Santos') quand client_name est un label — sert de prénom/nom Qonto. Optionnel.",
      +  "type": "string"
      +}
    • addedInput schema / properties / create_client_if_missing
      Added value: +{
      +  "description": "Si le client n'existe pas : le créer (sinon erreur explicite). Exige alors l'adresse ci-dessous.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / force
      Added value: +{
      +  "description": "Créer même si un document identique (même client, même total, même jour) existe déjà. Défaut false.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / items / description
      Added value: +"Lignes (au moins 1)."
    • addedInput schema / properties / items / items / properties / quantity / description
      Added value: +"Quantité (défaut 1)."
    • addedInput schema / properties / items / items / properties / title / description
      Added value: +"Intitulé de la prestation, ex. 'Mastering stéréo — Track X'."
    • addedInput schema / properties / items / items / properties / unit_price / description
      Added value: +"Prix unitaire HT en €."
    • addedInput schema / properties / request_id
      Added value: +{
      +  "description": "Identifiant unique de CET appel (ex. 'mate027-devis-2026-09-22'). Si le même request_id est rejoué (timeout, relance), le serveur renvoie la réponse d'origine sans rien recréer.",
      +  "type": "string"
      +}
    • addedInput schema / properties / street_address
      Added value: +{
      +  "description": "Adresse de facturation (rue) — obligatoire pour créer un client, sauf address_unknown.",
      +  "type": "string"
      +}
    • addedInput schema / properties / tin_number
      Added value: +{
      +  "description": "SIREN/SIRET (ou n° fiscal étranger) du client : rend le type company possible. Optionnel.",
      +  "type": "string"
      +}
    • addedInput schema / properties / vat_number
      Added value: +{
      +  "description": "N° TVA intracom du client créé (optionnel).",
      +  "type": "string"
      +}
    • addedInput schema / properties / zip_code
      Added value: +{
      +  "description": "Code postal — obligatoire pour créer un client, sauf address_unknown.",
      +  "type": "string"
      +}
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full disclosure burden and does so thoroughly. It reveals return payload, client lookup order, anti-duplicate behavior with force, request_id replay idempotency, absence of PDF in the response, and the address_unknown dash policy. This goes far beyond a minimal mutation description.

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

Conciseness5/5

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

Six dense, purposeful sentences in one block, front-loaded with the token restriction, action, and return values. Each clause earns its place: dedup, client creation, address policy, PDF routing, and state-check advice are all relevant to calling the tool correctly. No filler or repetition.

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

Completeness5/5

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

For an 18-parameter mutation tool with no output schema and no annotations, this description is remarkably complete. It covers return values, idempotency, client matching order, address requirements, and sibling handoffs. Minor error details are left to the schema, which already documents most parameter constraints.

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

Parameters4/5

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

Schema coverage is 94%, so most parameters are already well documented. The description adds meaning beyond the schema by explaining request_id replay semantics, force bypassing the duplicate check, create_client_if_missing requiring an address, address_unknown substituting dashes, and client_kind company requiring tin_number. It does not repeat parameter formats.

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?

States a specific verb and resource: it creates a Qonto client quote with document reference D-2026-XXX and lists the returned fields (numéro, total, lien client, id). The term 'devis' clearly separates it from the qonto_create_invoice sibling, so an agent can identify the correct tool without opening the schema.

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?

Explicitly scopes usage to the studio token and routes the agent to prepare_quote_email for sending and qonto_get for the PDF URL. It also advises qonto_list before retrying when state is uncertain. It does not explicitly enumerate when to use qonto_create_invoice instead, but the quote vs invoice distinction is clear enough from the names and resource.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources