mb-mastering

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

No annotations are provided, so the description carries full burden. It fails to disclose behavioral traits such as whether the operation is read-only, requires authentication, or has rate limits. The description only states the action without additional transparency.

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 extremely concise with two short sentences (one in each language). No wasted words 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?

Given the tool's simplicity (single parameter, no output schema), the description adequately states its purpose and source of input. It could be slightly more complete by specifying the format or type of full content, but overall 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 a description for 'id'. The tool description adds value by clarifying that the id comes from search results, which complements the schema's explanation.

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 fetches full content of a document by id, specifying the resource ('document MB Mastering') and linking to search results, which distinguishes it from sibling tools like get_faq or get_pricing.

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 indicates the tool should be used after search ('obtenu via search / from search results'), providing clear context. However, it does not explicitly state when not to use it or mention alternative tools.

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?

No annotations provided. The description indicates it returns FAQ answers, but does not explicitly state it is a read-only, non-destructive operation. It is adequate for a simple retrieval 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?

Single, concise sentence in French, front-loaded with the purpose, no wasted words 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?

Given no parameters and no output schema, the description sufficiently explains what the tool returns. It lacks details about output format, but for a simple FAQ tool, it 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?

No parameters are present, so schema coverage is 100% trivially. The description adds value by explaining the tool's scope and topics covered, which compensates for the absence of parameters.

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 it provides answers to frequently asked questions about mastering at MB Mastering, listing specific topics like pricing, deadlines, and revisions. It implicitly distinguishes itself from sibling tools like get_pricing (pricing only) and get_services (services list).

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?

No explicit guidance on when to use this tool versus alternatives like fetch, search, or get_pricing. The description does not mention when or 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.

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

No annotations are provided, so the description carries the full burden. It implies a read operation ('donne') but does not explicitly state it is non-destructive, idempotent, or safe. Adding a safety note would improve transparency.

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 a single, clear sentence with no wasted words. It is front-loaded and efficient, 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?

Given zero parameters and no output schema, the description covers the tool's purpose and key output categories. However, the lack of an output schema means the agent has no structured contract for the return value, slightly reducing completeness.

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, so schema coverage is 100%. The description adds context about what data is returned (rates, deadlines, etc.) but does not detail the output structure. A baseline of 4 is appropriate given no parameters.

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 retrieves pricing, deadlines, revision policy, and payment terms for MB Mastering. It uses a specific verb 'donne' and resource, distinguishing it from siblings like get_services or get_studio_info.

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 pricing queries but provides no explicit guidance on when to use this tool versus alternatives like get_services or get_faq. No exclusions or context triggers are mentioned.

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?

No annotations are provided, but the description indicates a read-only listing operation without detailing any side effects, authentication needs, or response structure.

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 a single, front-loaded sentence that efficiently conveys the tool's purpose and scope without any 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?

Given no parameters and no output schema, the description sufficiently explains what the tool returns, though it could mention that it is read-only or give example output.

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?

With zero parameters, the schema coverage is 100%, so the baseline is 4. The description adds no parameter details, but none are needed.

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 explicitly states the tool lists MB Mastering's services with their prices and descriptions, providing a specific verb and resource that distinguishes it from siblings like get_pricing and get_faq.

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 service listings but does not specify when to use this tool versus alternatives, such as get_pricing or send_quote_request.

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?

No annotations provided, but the description lists the type of information returned (founder, experience, address, equipment, links). It does not mention read-only nature or potential limitations, but these 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?

Single sentence, front-loaded with key information, no wasted words.

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 zero parameters, no output schema, and a simple purpose, the description fully and adequately specifies what the tool returns.

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?

No parameters, so the description does not need to add parameter-level details. Baseline score of 4 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 tool name and description clearly state it returns information about the MB Mastering studio. It distinguishes from sibling tools like get_faq, get_pricing, get_services which serve different purposes.

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 it (when needing studio info) versus alternatives like get_pricing or get_services, but does not explicitly state exclusions or prerequisites.

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?

With no annotations, the description carries the burden of disclosure. It states that the log includes both sent and filtered requests with reasons, which is useful behavioral context. However, it does not mention read-only nature, pagination, or behavior on invalid tokens. It adds value beyond the schema but leaves some gaps for a list 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?

Two concise sentences with no wasted words. The reservation note is front-loaded, and the purpose and use case are stated 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 simple list tool with three parameters and no output schema, the description covers the purpose, the distinction between sent/filtered, and the verification use case. It could mention response format or auth requirement more explicitly, but the token is hinted at, and the schema documents parameters. It's reasonably complete for an agent to understand when and how to use it.

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 covers days and verdict with descriptions (67% coverage). The description adds context by implying the verdict filter via 'envoyées par mail ET filtrées' and mentions the token reservation, but it does not explicitly explain parameter usage or formats beyond the schema. It provides marginal additional 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 clearly states the tool's function: it lists quote requests received via send_quote_request, distinguishing between those sent by email and those filtered as spam/robots, with the reason for filtering. This is specific and differentiates it from the sibling send_quote_request (which creates requests) and other 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 explicitly says it's reserved for the studio (token) and explains a primary use case: verifying that no legitimate request was filtered. While it doesn't mention alternatives or when not to use it, the reservation and verification purpose provide clear context for when an agent should invoke it.

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?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It details the default draft mode (stored in OVH webmail Drafts), send mode (immediate send and archive in Sent), the requirement of an admin token, and how the PDF is sourced/retrieved. This is thorough and surfaces side effects and constraints upfront.

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 text is a compact two-sentence block that front-loads the access restriction, clearly states the action and mode distinction, and ends with the PDF sourcing logic. Every sentence carries essential information without 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?

Given the tool's complexity (16 parameters, no output schema), the description covers the core semantics: intended purpose, modes, sender identity, and PDF handling. It doesn't explain return values or failure behavior, but the detailed parameter descriptions in the schema compensate; an agent has enough context to 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 description coverage is 100%, so each parameter is already documented. The description adds value by connecting qonto_type + qonto_number to the server-side PDF retrieval and pdf_base64 to external documents, clarifying the parameter relationships beyond individual schema entries. It doesn't duplicate every parameter, which keeps it focused.

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 specific verbs ('Prépare un brouillon — ou envoie') and names the resource ('email d'un devis ou d'une facture PDF à un client'), clearly distinguishing this emailing/PDF tool from document-management siblings like qonto_create_quote. It also states the sending address and the two PDF sources, leaving no doubt about the tool's role.

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 context for use: restricted to the studio, admin token required, draft mode by default vs immediate send mode, and the PDF retrieval options (Qonto or base64). It doesn't explicitly name alternatives or state when not to use it, but the context is strong enough for an agent to infer the correct situation.

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?

With no annotations, the description must disclose behavioral traits. It reveals the mutation (append or create) and the admin token requirement. It does not cover failure modes or idempotency, but the core side effect is 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?

Two concise sentences with the most critical info (reservation, token requirement) front-loaded. No wasted words.

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 is inadequate for a 7-parameter tool with no annotations or output schema. It doesn't explain how to specify the client (which of the three client fields), how quantity works, or what the response looks like. An agent would struggle to call it correctly without additional documentation.

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 only 14%, so the description must compensate by explaining parameters. It does not explain client_id, client_name, client_email, quantity, or auth_token. The only hint is the word 'client' and 'token d'administration', but it fails to map these to specific parameters or clarify which are required for client identification.

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 appends a line to an existing Qonto draft or creates the draft if absent, and distinguishes it from finalization via qonto_finalize_invoice. The specific verb 'ajoute' and resource 'ligne à un brouillon' make the purpose unmistakable and distinct from 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?

The description provides a concrete usage scenario (recurring clients like Antinote, DKO) and points to the complementary finalize tool. It does not explicitly state when not to use it, but the context is clear enough. The admin token requirement is also mentioned, giving a prerequisite.

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?

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses idempotency via request_id, same-day duplicate refusal, force=true override behavior, the absence of PDFs in responses, and the client lookup priority (id, email, then name).

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 dense but efficiently structured: purpose first, then client resolution, duplicate protection, and PDF alternatives. Every clause earns its place, and it is not padded with redundant schema 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?

Despite 19 parameters and no output schema or annotations, the description is complete enough for an agent to invoke the tool safely: it covers statuses, return values, client creation, idempotency, duplicate handling, and the correct sibling tools for sending and PDF retrieval. Remaining parameter details live in a fully covered schema.

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 baseline is 3, but the description adds cross-parameter meaning beyond individual schema descriptions: client matching precedence, the condition that create_client_if_missing requires an address, and how request_id prevents duplicate creation. This synthesis helps an agent choose and combine parameters correctly.

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: "Crée une facture client Qonto", and clarifies the status variants (draft/proforma vs unpaid official). It also states what the tool returns (numéro, total, lien de paiement Mollie) and explicitly routes PDF-related needs to sibling tools, distinguishing it from prepare_quote_email and qonto_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 context on when to use this tool versus alternatives: it creates invoices, not PDFs, and explicitly says to use prepare_quote_email for sending and qonto_get for the PDF URL. It also explains client resolution order and creation behavior, though it does not explicitly say "use qonto_create_quote for quotes" — the distinction is implied by the word facture.

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?

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.

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.

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.

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.

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.

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.

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

The description discloses the destructive nature of the operation, the state restrictions, and the confirmation mechanism. It also reveals that the first call without confirm returns a summary, which is a behavioral trait not visible in the schema. However, it doesn't mention auth requirements beyond the reserved token note, and there are no annotations to contradict.

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 most important constraint (reserved for studio token). Every sentence adds value: what it deletes, what it refuses, and the confirmation requirement. No wasted words.

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 destructive tool with no annotations and no output schema, the description covers the critical aspects: target states, refusal conditions, and confirmation flow. It could mention what the summary response contains or what happens after deletion, but the essential information for safe invocation is present.

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 description adds meaning to the confirm parameter by explaining the two-step deletion flow, and clarifies the type parameter's default (quote). It also explains the number parameter's role (document number or Qonto id). With 60% schema coverage, the description compensates for the undocumented id and auth_token parameters by giving context on the deletion flow.

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 deletes pending quotes or draft invoices, with a concrete example (duplicate created by mistake). It distinguishes itself from siblings like qonto_create_invoice and qonto_finalize_invoice by specifying the exact document states it operates on.

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 says when to use it (pending_approval quotes, draft invoices) and when not to use it (refuses sent/approved/finalized documents). It also explains the confirm=true requirement and the two-step behavior, which is essential usage guidance.

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?

No annotations are provided, so the description carries the full burden. It discloses that the operation mutates the invoice status to 'unpaid', generates PDF and payment link, and requires an admin token. However, it does not mention potential side effects (e.g., irreversibility), what happens if the draft is not found, or error handling. For a mutation tool, this is a moderate gap, but the core behavior is described.

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 a single, dense sentence in French. It front-loads the restriction and action, then details the effect and lookup methods. It is concise with no filler, though it could benefit from bullet points or explicit separation of prerequisites and lookup options. Still, it earns a high score for efficiency.

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 the tool has 5 parameters, no annotations, and no output schema, the description covers the essential purpose and identifier logic, but lacks details on error cases, response format, and any side effects like irreversibility. For a sensitive financial operation, an agent might need more guidance on what to expect. The description is adequate but not comprehensive.

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 0%, so the description must compensate. It does: it clarifies that auth_token is the admin token, and that invoice_id or any of client_id/email/name can be used as alternative identifiers. It implies that at least one of these identifiers is needed, adding meaning beyond the bare schema. It does not explicitly state requiredness, but the context is clear.

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: finalizes a draft (proforma) into an official numbered invoice, changing status to 'unpaid' and generating PDF and payment link. It explicitly distinguishes itself from creation tools like qonto_create_invoice by focusing on existing drafts. The verb 'finalize' and resource 'invoice' are specific, and the scope (reserved for studio) is clear.

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 explicit usage context: it is reserved for studio use and requires an admin token. It also explains the two alternative lookup methods (by invoice_id or by client details). While it does not explicitly say 'do not use for creating new invoices', the distinction is clear from the purpose and sibling tool names. This is sufficient guidance for an agent to know when to call it.

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?

No annotations are provided, so the description carries the full burden. It discloses that the PDF URL is temporary, that base64 is never returned, and that a token is required (reserved for studio). However, it does not explicitly state the operation is read-only or describe error behavior, leaving some behavioral gaps.

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 a single dense sentence, front-loaded with the access restriction, then the core purpose and return fields. There is no fluff; every clause adds information, making it efficient and well-structured.

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 main return fields and important caveats (temporary URL, no base64), and mentions the access token. It lacks explicit error handling or response structure, but for a simple get tool with no output schema, it provides sufficient context 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 coverage is 75% (auth_token lacks a description). The description adds value by explaining the number format (D-2026-003, F-2026-001), that id is an alternative, and that a token is needed. This goes beyond the schema's minimal descriptions, clarifying usage of the parameters.

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 retrieves detailed information for a single Qonto quote or invoice by number or ID, listing the specific fields returned (lines, client+address, status, links, PDF URL). This distinguishes it from siblings like qonto_list (listing) and qonto_create_* (creation) by focusing on a single document.

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 the tool is for retrieving details of one document, which is distinct from listing or creating. However, it does not explicitly mention alternatives or when-not-to-use it, relying on the tool name and purpose to differentiate from siblings.

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?

With no annotations, the description must carry the burden of behavior. It discloses the return fields and the studio-token restriction, and 'Liste compacte' implies a read-only listing. However, it does not explicitly state that the tool has no side effects, nor does it describe pagination, ordering, or error behavior beyond the schema's limit field.

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 short sentences with no filler. The access restriction is front-loaded, the core purpose and output fields are in the first sentence, and the specific usage scenario is in the second. 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?

The description is complete for a simple list tool: it states the purpose, the resource types, the return fields, the access restriction, and a key usage scenario. It lacks explicit confirmation of read-only behavior and does not mention pagination or response format, but the schema and output field list cover most of what an agent needs 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 coverage is 80%, so the baseline is 3. The description adds value by clarifying that auth_token should be a studio token ('RÉSERVÉ AU STUDIO (token)'), which is otherwise undocumented in the schema. It also connects the resource types (quotes/invoices/clients) to the 'type' parameter, adding semantic context beyond the enum names.

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: it returns a compact list of Qonto quotes, invoices, or clients, with a clear field set (number, status, total, date, client, id). It does not explicitly contrast itself with sibling tools like qonto_get or list_quote_requests, but the resource scope and 'compacte' qualifier make the purpose reasonably distinct.

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 concrete usage context: call this tool before retrying a creation when a previous call seemed to fail. It also states that the tool is reserved for the studio token. It does not name alternatives or exclusion criteria, so it falls short of a 5, but the guidance is clear and actionable.

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?

With no annotations provided, the description must carry the full burden of behavioral disclosure. It discloses that an admin token is required (auth requirement) and that the action updates the billing address (a mutation). However, it does not describe the response format, whether the update is idempotent, or any side effects (e.g., overwriting existing address). This is a moderate gap for a mutation tool, so a 3 is appropriate.

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 short sentences with zero fluff. The access restriction is front-loaded, followed by the core purpose and identification guidance. Every sentence contributes to the tool's usability, making it highly concise and well-structured.

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 purpose, identification, and auth requirements, but it omits details about the response (e.g., whether it returns the updated client) and potential error conditions. Given there is no output schema and no annotations, the description could provide more behavioral context. For a tool with 8 parameters and 3 required, this is adequate but not complete, so a 3 is appropriate.

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 all parameters. The description adds value by clarifying that client_id is the preferred identifier and that client_email/client_name are fallbacks, and it implies the address fields (street_address, city, zip_code) are the ones being updated. This guidance goes beyond the schema's individual field descriptions, so the description earns a 4.

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: 'Met à jour l'adresse de facturation d'un client Qonto existant' (updates the billing address of an existing Qonto client). This clearly distinguishes it from siblings like qonto_create_invoice (create vs update) and other non-Qonto tools. The identification methods (client_id, client_email, client_name) are also specified, leaving no ambiguity about the tool's function.

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: 'RÉSERVÉ AU STUDIO (token d'administration requis)' indicates it is only for the studio and requires an admin token, and it recommends client_id as preferred over client_email/client_name. However, it does not explicitly mention when not to use the tool or alternatives (though no direct alternative exists). The prerequisite and identification preference provide solid guidance, so it earns a 4.

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?

Describes output structure (id, titre, extrait, URL) and content coverage, which is helpful. No annotations, so description carries burden; could mention it's read-only or any limitations.

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 concise sentences in two languages, no fluff, front-loaded with main action.

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 simple tool with one parameter and no output schema, description covers what it searches and returns. Could add guidance on when to use vs siblings.

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?

Only one parameter 'query' with description in schema; description adds no extra semantic detail beyond that.

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?

Clear verb 'recherche/searches' and specific resource 'MB Mastering content' including categories. Distinguishes from sibling tools like get_faq or get_pricing which target specific sections.

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?

Implies use for general search across content, but no explicit guidance on when to prefer this over dedicated sibling tools. No when-not-to-use statements.

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?

No annotations are provided, so the description must disclose behavioral traits. It only mentions sending an email and required fields. It does not specify side effects, persistence, idempotency, confirmation, or error handling, which is insufficient for a tool that performs an 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?

The description is concise with three sentences that are direct and to the point. It avoids unnecessary details, but could be considered slightly under-specified given the parameter count.

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 should clarify the tool's return behavior or outcome (e.g., a confirmation or error). It lacks any mention of what happens after the request is sent, leaving the agent without a complete understanding of the tool's lifecycle.

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 description reiterates required fields but adds no additional meaning beyond the schema. It does not explain parameter relationships or provide extra usage tips.

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 (sends a request), the resource (mastering quote), the recipient (MB Mastering), and the method (email). It distinctly positions the tool as a request submission tool, differentiating it from the sibling tools that fetch or retrieve information.

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 a use case: 'to be used when the user wishes to be contacted.' This is helpful but lacks explicit guidance on when not to use the tool or what alternatives exist among siblings. It is minimal but adequate.

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?

With no annotations provided, the description carries the full behavioral burden and delivers thoroughly: admin-token requirement, chunked upload protocol (chunk_index=0 first, is_last=true last), return behavior (URL returned on final chunk), confinement to a hardcoded path, and strict sanitization with no path escape possible. This is substantially richer than a typical summary.

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?

Each sentence earns its place: access restriction first, then the action, filename behavior, chunking protocol, and safety boundary. The most critical constraint is front-loaded, and there is no filler or redundant restatement of the schema.

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 5-parameter tool with no annotations and no output schema, the description covers access control, target path, chunking flow, return value, and security guarantees. The main gap is the absence of failure/retry semantics for multi-chunk uploads (e.g., what happens if a chunk fails mid-sequence), but overall it is well above minimal viability.

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, but the description adds orchestration semantics beyond the per-field schema: it explains how chunk_index and is_last interact within the upload sequence, and that the final chunk triggers the client URL return. This cross-parameter protocol knowledge is genuinely additive, not just a restatement.

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?

States a specific action ('Dépose un zip de master client'), resource, and destination ('dans ~/www/masters/ sur le serveur OVH'). The verb is concrete and the resource is well-defined. It clearly stands apart from the sibling tools, which are all read/fetch/search operations, making it the only write/upload tool.

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 opens with a hard usage restriction: 'RÉSERVÉ AU STUDIO (token d'administration requis)', giving clear conditions under which the tool may be called. It does not explicitly name alternatives or exclusion conditions relative to siblings, but the sibling context (all read-only information tools) makes the differentiation evident and the access requirement is unambiguous.

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