MCP Dolibarr Expert

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.1.0
Disambiguation2/5
With 183 tools, many boundaries blur: list_payments and list_bank_transactions both list bank transactions, list_expenses overlaps with list_expense_reports, and get_thirdparty_invoices duplicates list_invoices with a different name. The nine configure_* guides and multiple financial summary tools (get_financial_summary, get_accounting_dashboard, get_activity_stats) create selection ambiguity.
Naming Consistency4/5
Most tools follow a verb_noun pattern (list/get/create/update/validate + entity), which is readable and predictable. However, there are inconsistencies such as list_supplier_payments actually listing paid supplier invoices rather than payments, and get_thirdparty_invoices should logically be list_thirdparty_invoices to match related list_thirdparty_* tools.
Tool Count1/5
183 tools is extreme for an MCP surface, far exceeding the 50+ threshold. Even for a full ERP, this overwhelms an agent with context and selection cost, making it impractical for efficient tool discovery.
Completeness3/5
Coverage is extensive across many Dolibarr modules, including invoices, orders, products, accounting, HR, and manufacturing. However, core entities like invoices, orders, proposals, and tickets lack update/delete operations, and several create-only tools (warehouse, category, contract) have no corresponding lifecycle closure, leaving notable dead ends.
Average 3.1/5 across 180 of 183 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 3 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention side effects, permissions, reversibility, or what the tool actually changes. 'Guide pour configurer' is vague and does not even clearly state that it mutates invoice settings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not concise; it is under-specified. A single vague sentence does not earn the right to be brief because it omits necessary information. There is no structure, front-loading, or useful elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a configuration tool with 4 undocumented parameters and no output schema, this description is completely inadequate. It provides no information about the meaning of parameters, the effects of the operation, or how the tool relates to other invoice/configuration tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes 4 parameters with 0% coverage in the description. The description does not mention any parameter names or meanings, so an agent cannot infer what values to pass (e.g., can_be_edited as a boolean-like number).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Guide pour configurer les options de facturation' restates the tool name without adding specific functionality. It does not list which invoice options are configured or distinguish itself from sibling configuration tools like configure_vat_mode. The word 'Guide' may also mislead an agent into thinking this is documentation rather than an actionable tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclusions. With no usage context, an agent cannot decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only says 'Validate a manufacturing order' with no information about side effects, state changes, permissions, reversibility, or what 'validation' means in this context. This is a complete lack of behavioral transparency 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than concisely informative. It provides no value beyond the tool name, so it is not appropriately sized; it omits essential behavioral and usage information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a validation tool that presumably mutates state, with no annotations, no output schema, and a single under-documented parameter, the description is grossly incomplete. It does not explain what validation does, what the id is, or what the outcome of the operation is, making it inadequate for safe and correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate by explaining the 'id' parameter. It does not mention 'id' at all, nor does it clarify that the id refers to a manufacturing order. The agent must infer this from the tool name, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Valider un ordre de fabrication' directly translates the tool name 'validate_manufacturing_order' without adding any new information. It is a tautology that restates the resource and action already present in the name, so it fails to add purpose clarity beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives like create_manufacturing_order, get_manufacturing_order, or produce_manufacturing_order. The description does not mention prerequisites, conditions, or any exclusion criteria, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects, permissions, or return values. It only states a purpose without revealing whether the action is safe, reversible, or what changes occur. This is a significant gap for a configuration tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, but it is under-specified rather than concise. It lacks necessary detail about parameters and behavior, so it does not earn its place as a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and parameter descriptions, this description is woefully incomplete. It does not explain how to configure invoice numbering, what each parameter does, or what the tool returns, making it inadequate for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters (model, show_rib, pdf_model) with zero descriptions, and the description does not mention any of them. Schema coverage is 0%, so the description must compensate but fails to explain parameter meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Guide pour configurer la numerotation des factures' clearly identifies the resource (invoice numbering) and the action (configuring), but the use of 'Guide' makes it sound like documentation rather than a direct action. It does not specify what configuring entails or distinguish it from sibling configure tools like configure_invoice_options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks any context about prerequisites, scenarios, or exclusions, and many sibling tools share the 'configure_' prefix, making it impossible to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description must disclose behavioral traits but fails entirely. It does not state whether refusal is reversible, what status changes occur, whether permissions are required, or any side effects. The description is only a short phrase with zero behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but this is under-specification rather than efficient conciseness. A four-word phrase is not a structured or informative description; it reads more like a label than a usable tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing tool with no annotations, no output schema, and minimal parameter descriptions, the description is grossly incomplete. It does not explain the refusal workflow, the consequences, or how this fits among the many expense report sibling tools, making it inadequate for an AI agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema. The schema documents 'detail' as 'Motif du refus' and leaves 'id' undocumented; the description does not compensate for the 50% coverage gap or clarify how parameters relate to the refusal action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Refuser une note de frais' is a direct French translation of the tool name 'refuse_expense_report', adding no new information about the action or resource. It does not differentiate this tool from sibling actions like validate, approve, or pay expense reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as validate_expense_report or approve_expense_report. The description does not mention any prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 does not mention return format, pagination, sorting, authentication, or any side effects. The noun phrase provides no insight into how the tool behaves beyond the basic subject matter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (a single phrase), which is concise, but it lacks proper sentence structure and front-loading. It under-specifies rather than earning its place with informative content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and minimal schema info, the description should compensate. It fails to explain what the tool returns, what status values exist, or how limit behaves. The description is grossly incomplete for a tool with two parameters and no other documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines two parameters (limit, status) with no descriptions and schema description coverage is 0%. The description does not mention these parameters at all, leaving their meaning and usage completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase 'Paiements en ligne reçus (Stripe/PayPal)' which identifies the resource as received online payments from Stripe/PayPal. It adds context beyond the tool name, distinguishing it from broader payment tools like list_payments, but lacks an explicit verb or statement of what the tool does (e.g., 'Lists...').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_payments or list_supplier_payments. The mention of 'online' and 'Stripe/PayPal' implicitly suggests a specific subset, but there is no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Refuse a leave request' and fails to mention side effects, status changes, authorization requirements, reversibility, or any other behavioral traits. The description is a bare action phrase with zero behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which makes it concise in length. However, it is under-specified and merely restates the tool name, so it does not 'earn its place'. It lacks any informative content, making it not appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation action (refusing a leave request) with no annotations, no output schema, and two parameters. The description only states the action and provides no context about the workflow, effect on the request, or expected inputs/outputs. It is inadequate for an agent to understand when and how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the parameters. The input schema provides a description for 'motif' (reason for refusal) but none for 'id'. With schema description coverage at 50%, the description should compensate by clarifying what 'id' refers to (e.g., the leave request ID), but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Refuser une demande de congé' is a direct French translation of the tool name 'refuse_leave_request'. It restates the name without adding any additional context or differentiating from sibling tools like 'approve_leave_request'. While it does use a specific verb and resource, it is essentially a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'approve_leave_request'. It merely states the action without any context on prerequisites, workflow position, or conditions for refusal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description gives no behavioral information. It does not disclose side effects, permission requirements, or whether this is a write operation beyond the verb 'create'. The description carries zero behavioral burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It provides no useful structure or elaboration for a tool with six parameters and no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters, no output schema, and no annotations. The description offers no context about what a BOM is, how it relates to manufacturing orders, or what the response will be. It is completely inadequate for an agent to know how to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83% (5 of 6 properties have descriptions), so the baseline is 3. The description adds no parameter-level meaning, but since the schema already documents most parameters, the tool description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Créer une nomenclature de fabrication' translates directly to 'Create a manufacturing BOM', which essentially restates the tool name 'create_bom' without adding detail. It does not distinguish this tool from siblings like create_manufacturing_order or list_boms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not explain when to use this tool versus alternatives, nor does it mention prerequisites or typical scenarios. It is a single phrase with no guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'create' without explaining side effects (e.g., stock impact, BOM validation), required permissions, or reversibility. This is a mutation tool with zero behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short phrase is technically concise, but it is under-specification rather than effective conciseness. Every word restates the tool name, providing no informative content, so the minimalism is not earned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter manufacturing order creation tool with no annotations and no output schema, this description is completely inadequate. It fails to explain return values, workflow integration, or operational constraints, making it unsafe for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 88%, so the schema already documents 7 of 8 parameters well. The description adds no parameter meaning beyond the schema, and note_public remains undocumented. Baseline 3 is appropriate since the description neither compensates for gaps nor adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Créer un ordre de fabrication' is a direct French translation of the tool name, making it a tautology. It restates the name without adding a distinct verb+resource specification or differentiating from sibling tools like validate_manufacturing_order or produce_manufacturing_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as validate_manufacturing_order, produce_manufacturing_order, or list_manufacturing_orders. There is no mention of prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only says 'create a new project' and gives no indication of side effects, permissions required, return values, or any operational characteristics beyond the implied write action from the verb 'create'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only a single sentence, but it is under-informative rather than appropriately sized. For an 8-parameter tool, one sentence that merely restates the name is too sparse, and the sentence does not earn its place by adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, no annotations, and no output schema, yet the description provides no context about the creation process, required steps, return values, or any operational detail. It is completely inadequate as a standalone description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, with each of the 8 parameters (ref, socid, title, status, date_end, date_start, description, budget_amount) having its own description. Since the schema fully documents parameters, the description's lack of param info is not a penalty, and the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Créer un nouveau projet' is a direct French translation of the tool name 'create_project', restating exactly what the name implies without adding specific detail. It is a tautology that offers no additional information about the tool's scope or what distinguishes it from other create_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or context. It is a bare statement with no situational advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely states 'create a category' with no mention of side effects, required permissions, uniqueness constraints, or what happens on creation. The tool appears to be a mutating operation, but the description gives no 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three words, but this is under-specification rather than conciseness. It does not earn its place because it simply repeats the tool name. A valuable description would add context or detail while remaining brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 5 parameters, no annotations, and no output schema, the description is severely inadequate. It provides no context about category types, the meaning of 'type' values (though the schema helps), or what the response will be. The tool is incompletely specified for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80% (4 of 5 parameters have descriptions), so the schema already provides the semantic meaning for most parameters (type, color, label, fk_parent). The description adds no parameter information. Per baseline rules, with high schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Créer une catégorie' is a direct French translation of the tool name 'create_category'. It restates the name without adding any specific detail about what a category is, its purpose, or how it differs from sibling tools like list_categories or add_object_to_category. This is a tautology, not a clarifying description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention prerequisites, typical use cases, or any exclusions. Sibling tools exist for viewing or adding objects to categories, but no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. However, it offers no information about side effects, read-only nature, data access, or what the tool does besides the noun phrase. It does not even explicitly state that it retrieves configuration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single noun phrase. It is front-loaded and free of fluff, but it is under-specified and not a complete sentence, which reduces clarity. It earns a middle score for brevity without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is insufficiently informative. It does not state what the configuration contains, what format the return value takes, or how it relates to other configuration tools. An agent would not know what to expect from calling this tool.
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?
The input schema has zero parameters, so the baseline is 4. The description adds a small amount of context by indicating the tool concerns client portal configuration, which aligns with the empty schema. No parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Configuration du portail client Digital Factory' identifies the resource (client portal configuration) but does not use an explicit verb, relying on the tool name 'get' for the action. It also does not distinguish this tool from other configuration-related siblings like 'get_setup_values' or 'get_company_info'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as 'get_setup_values' or 'configure_*' tools. The description provides no context about the intended use case, prerequisites, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It provides no information about pagination defaults, return structure, or read-only nature, leaving the agent without expectations beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and front-loaded. However, it is too terse to provide meaningful structure or additional context, though it does state the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity but lack of output schema and annotations, the description is insufficient. It does not explain what fields are returned, how pagination works, or how the status filter behaves, making it incomplete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only 25% description coverage (status field only), and the tool description offers no additional parameter semantics. The description does not mention pagination, filtering, or status usage, so the agent must rely entirely on schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List supplier orders' clearly identifies the action (list) and resource (supplier orders), making the primary purpose evident. However, it does not distinguish this tool from related list tools like list_orders or list_supplier_invoices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_orders or list_supplier_invoices. There is no mention of preconditions, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral implications, but it only says 'configure' without explaining side effects, permissions, or whether changes are reversible. It does not mention what happens to existing settings or whether this is a write operation with potential destructive consequences.
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?
The description is a single concise sentence, which is efficient and front-loaded. However, it is so brief that it sacrifices informative content, though for a one-line description it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters, no annotations, no output schema, and no parameter descriptions. The description is far too sparse to be considered complete for an agent to select and invoke the tool correctly, especially given the existence of many related accounting configuration tools in the sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no explicit mapping for the parameters (account_id, journal_code, accounting_number). It only hints at the concept of an accounting account but does not explain how each parameter relates to the configuration. This leaves the agent without adequate semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Configurer' = configure) and a specific resource ('le compte comptable d'un compte bancaire' = the accounting account of a bank account). It conveys the tool's main function without ambiguity, though it does not explicitly differentiate from similar accounting configuration tools like 'set_accounting_account_mapping' or 'configure_accounting_autolettering'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not explain when to use this tool compared to other accounting configuration tools, nor does it mention prerequisites or exclusions. Users are left to infer the appropriate context from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It says 'Fournit les URLs Dolibarr' (provides Dolibarr URLs), which suggests the tool returns URLs or a guide rather than directly changing settings, but this is ambiguous given the tool name 'configure_vat_mode'. It does not mention side effects, required permissions, or the nature of the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences), but this conciseness comes at the cost of essential information. It front-loads the purpose but omits parameter semantics and behavioral details. It could be expanded to include parameter explanations while remaining concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and only a minimal description, the tool is significantly under-specified. The agent learns only that the tool relates to VAT mode and provides Dolibarr URLs, but it lacks context on what inputs are needed, what outputs to expect, and how this fits with other configuration tools. The low complexity suggests the description could easily be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains 4 string parameters (buy_product, buy_service, sell_product, sell_service) with no descriptions and 0% schema coverage. The description does not explain these parameters or how they relate to VAT mode configuration, leaving the agent completely in the dark about what values to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a guide for configuring VAT mode ('mode TVA (debits/encaissements)') and that it provides Dolibarr URLs. This names a specific resource and action, distinguishing it from other configuration tools. However, the French phrasing may slightly obscure the exact function for non-French speakers, and it does not explicitly contrast with sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool instead of other configuration tools like configure_fiscal_year or configure_invoice_numbering. The description implies it is for VAT mode configuration, but it offers no context on prerequisites, scenarios, or alternatives, leaving the agent to infer on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 only says 'Record a donation' and does not disclose permissions, effects, success/failure behavior, or any related operations. This is a significant gap 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single short phrase. It is front-loaded, but it is under-specified given the tool's complexity (5 parameters). It is not as tautological as 'Process' but still lacks substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is grossly incomplete. There are 5 parameters, no annotations, no output schema, and no behavioral context. The one-phrase description leaves the agent with no understanding of how to invoke the tool correctly or what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of what the parameters (amount, date, socid, public, note_public) mean. The description does not compensate for the lack of schema documentation at all.
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 description 'Enregistrer un don' clearly states the action (record/save) and the resource (a donation), distinguishing it from sibling read tools like get_donation and list_donations. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description gives no context on when to use this tool versus alternatives, no prerequisites, and no mention of required fields or side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and does not disclose side effects, required permissions, or any behavioral constraints beyond the name itself.
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?
The description is a single short sentence, making it very concise and front-loaded. It avoids unnecessary verbosity, though it could be slightly more informative without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no annotations, no output schema), the description is severely incomplete. It does not explain return values, required fields, or any operational context. It is not sufficient for an agent to invoke the tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter-level information. With schema description coverage at only 20%, the description should compensate for the undocumented parameters, but it does not. All 10 parameters are left unexplained beyond the field names, some of which are not self-explanatory (e.g., typeid, datefin).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Créer un nouveau membre/adhérent' clearly states the action (create) and the resource (member). It is specific but does not differentiate from sibling tools like 'subscribe_member' or 'create_contact', so it lacks explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description simply states the action without mentioning any context, prerequisites, or comparison to sibling tools like 'subscribe_member' or 'create_contact'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Lister' implies a read-only operation, but the description doesn't disclose pagination, default limits, whether all statuses are included, or any side effects. It adds no behavioral context beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (4 words in French), which is concise but under-specified. It omits essential usage and parameter information, so the brevity is not a virtue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is inadequate. It doesn't explain return values, pagination, or the meaning of sqlfilters. The low complexity of a list operation doesn't excuse the lack of context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (status has a description; limit and sqlfilters do not). The tool description adds no parameter explanations. Since coverage is low, the description should compensate but instead offers zero parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lister les membres/adhérents' clearly states a list operation on member resources. It distinguishes from sibling tools like get_member, create_member, subscribe_member, and list_member_types by describing a plural listing action. However, it doesn't include any scope or filtering nuance, so it's clear but not enriched.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of filters, default behavior, or when to use list_member_types or get_member instead. This is a complete absence of usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Add a line' and adds no information about side effects (e.g., whether the invoice totals are recalculated), error conditions, required permissions, or reversibility. This is a mutation tool with zero behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is under-specification rather than effective conciseness. It merely restates the tool name in French and does not provide any additional valuable content, making it too short to be useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter mutation tool with no annotations, no output schema, and no parameter documentation, the description is severely incomplete. It omits prerequisites, return values, error scenarios, and any behavioral context, leaving the agent without essential information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not mention any parameters or explain their meaning. It provides no compensation for the schema's lack of documentation, leaving the agent to infer semantics solely from parameter names like 'id', 'subprice', 'qty', and 'tva_tx'.
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 description clearly states the tool's function: adding a line to a supplier invoice. It uses a specific verb ('Ajouter') and resource ('ligne à une facture fournisseur'), and it distinguishes from sibling tools like add_invoice_line (customer invoice) and add_supplier_order_line (supplier order) by specifying 'fournisseur' and 'facture'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for supplier invoices but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as the invoice needing to be in draft status or the need for existing invoice id. Usage context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it fails. It does not state whether the update is partial or full replacement, what happens to unspecified fields, if it requires special permissions, or what the response contains. This is a significant transparency gap.
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?
The description is a single, front-loaded sentence that efficiently states the core purpose. It contains no filler or redundancy. However, its brevity comes at the cost of missing essential context, but that is penalized under other dimensions. For conciseness, it earns high marks for being succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, no output schema, and no annotations, this description is woefully incomplete. It does not explain return values, error behavior, validity constraints, or the semantics of each field. It provides only the most basic statement of intent, leaving the agent without enough information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is only 9% (only 'id' is described). The description provides no additional meaning for the 10 other parameters (zip, name, town, email, phone, client, address, fournisseur, note_public, note_private) nor does it explain how they relate to updating a third party. The description does nothing to compensate for the low schema coverage.
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 description clearly states a specific action ('Mettre à jour' = update) on a specific resource ('les informations d'un tiers existant' = information of an existing third party). It distinguishes itself from sibling tools like create_thirdparty (create) and get_thirdparty (read) by emphasizing 'existing' and 'update'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when to prefer update_thirdparty over create_thirdparty or other update tools, or any exclusions. The description is a single declarative sentence with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing side effects. It only says 'assign a ticket to a user' without specifying whether it changes the ticket status, sends notifications, is reversible, or requires special permissions. For a mutation tool, this is a significant omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically correct sentence with no fluff. However, it is essentially a reiteration of the tool name with slightly more context ('to a user'), offering no additional structural benefits. It is concise but under-specified, so it doesn't earn a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with two required parameters, no output schema, and no annotations, the description is incomplete. It lacks behavioral details, parameter clarification, and usage context. The user would be left uncertain about the tool's full effects and requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (user_id is described, id is not). The description adds minimal meaning: it implies one parameter is the ticket and the other the user, but it doesn't explicitly state that 'id' refers to the ticket ID. The user_id description already covers that parameter, so the description adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: assigning a ticket to a user. It uses a specific verb ('assigner') and resource ('ticket'), distinguishing it from sibling tools like create_ticket or close_ticket. However, it doesn't explicitly differentiate itself from those siblings, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as the ticket existing or the user being eligible, nor does it say whether to use it before resending or closing a ticket. No context is provided for when this action is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only says 'guide to activate', but does not clarify whether this is a write operation, what settings are modified, or any side effects. It fails to inform the agent about the tool's impact.
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?
The description is a single, short sentence that is concise and front-loaded with the key purpose. However, it is so brief that it borders on under-specification, but it earns points for having no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, no annotations, and no output schema, the description is inadequate. It explains neither the individual parameters nor the expected outcome beyond 'activating' something. The description does not cover enough ground for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (enable_lettering, enable_autolettering) with 0% schema description coverage. The description does not mention these parameters at all, providing no meaning beyond the bare field names. The agent is left without any idea of valid values or their roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: guiding the activation of automatic accounting lettering. This is specific and distinguishes it from sibling configuration tools like configure_vat_mode or configure_invoice_options. However, it lacks an explicit verb like 'configure' or 'activate', relying on the noun 'guide'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus other accounting configuration tools. There are no mentions of context, prerequisites, or which scenarios call for automatic lettering, leaving the AI agent without direction on selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the creation action and does not mention any side effects, required permissions, or workflow implications. This is insufficient for an agent to understand the full impact of invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief but largely redundant with the tool name, adding minimal informational value. It lacks the structural elements that would make it useful, such as context or examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
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 output schema, and no annotations, the description is far too minimal. It doesn't explain the relationship between the required parameters (e.g., date_debut/date_fin) or what happens upon creation, making it inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all 5 parameters, so the baseline is 3. The tool description adds no additional parameter guidance or relationships, so it stays at baseline.
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 description 'Créer une note de frais' clearly indicates the action of creating an expense report. It uses a specific verb and resource, distinguishing it from related tools like list_expense_reports or validate_expense_report. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no mention of when to use this tool versus alternatives such as get_expense_report or add_expense_report_line. No usage context or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only says 'create a leave request' with no information about side effects, validation, approval flow, or potential errors. This is a bare tautology that adds no behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than efficient conciseness. A single phrase doesn't provide adequate information for an agent to understand the tool's function or usage. It earns no credit for compactness because it omits essential content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 7 parameters and no output schema, this description is entirely insufficient. It fails to explain the effects, required fields, or typical usage scenario. The agent would need external knowledge to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86%, so most parameters already have descriptions. The tool description adds no parameter details beyond the schema, but the baseline of 3 applies because the schema carries the load adequately.
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 description 'Créer une demande de congé' clearly states a specific verb (create) and resource (leave request), distinguishing it from sibling tools like list_leave_requests or approve_leave_request. Even though it's short, it unambiguously conveys the action and object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description simply restates the action without context, exclusions, or references to related tools. No mention of prerequisites like employee existence or validation workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'create a salary record.' It does not mention side effects, permissions, financial implications, whether the record is immediately active, or any other behavioral traits. This is a significant gap for a financial creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is efficient, but it is under-specified for a tool with seven parameters and no annotations. It is not tautological, but the extreme brevity borders on under-specification rather than ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 7 parameters, no output schema, and no annotations, the description is insufficient for full understanding. It does not explain what a salary record entails, the creation workflow, or any consequences. The schema covers parameter syntax, but contextual completeness is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with French descriptions, so the schema already provides the meaning. The tool description adds no additional parameter context beyond the schema, justified by the high coverage, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Créer une fiche de salaire' clearly states the action (create) and the resource (salary record/payslip), distinguishing it from sibling tools like list_salaries and get_salary. It is a specific verb+resource pair, but the term 'fiche de salaire' is somewhat ambiguous (could mean salary sheet or payslip) and lacks further detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no mention of prerequisites, and no reference to related tools (e.g., get_salary or list_salaries). The description simply states the action without any contextual or usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits but only states the creation action without mentioning side effects, required permissions, or whether any validation occurs. It offers no additional context about the mutation, such as return values or idempotency, despite the tool being a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the one-sentence description is concise, it is under-specified and merely restates the tool name in French. It does not earn its place by adding useful information, falling into the category of under-explanation rather than efficient brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with 6 parameters and no output schema or annotations, the description is highly incomplete. It lacks information about required fields, expected behavior after creation, or any preconditions, making it minimally viable but with significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 6 parameters with 0% description coverage, and the description does not compensate by explaining any fields. It fails to clarify required parameters (ref, label) or optional ones (zip, town, etc.), leaving meaning entirely to the raw 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 description 'Créer un nouvel entrepôt' clearly states the tool creates a new warehouse, with a specific verb and resource. It distinguishes itself from sibling tools like list_warehouses and get_warehouse by indicating it is the create operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention related list/get warehouse functions, prerequisites, or scenarios where creation is appropriate, offering no more context than the tool name itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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-only operation ('Détails') but provides no information about return format, potential errors, required permissions, or side effects. For a simple retrieval tool this is minimal, but it still leaves key behavioral aspects undisclosed.
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?
The description is a single short phrase, 'Détails d'une transaction bancaire', which is concise and front-loaded. It contains no unnecessary words. However, it sacrifices informativeness for brevity, which is a slight issue but conciseness itself is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two required parameters, no output schema, and no annotations, this one-line description is insufficient. It does not clarify how the parameters identify the transaction, what the returned details might include, or how this tool relates to the many payment and banking siblings. The French phrasing may also cause ambiguity for non-French agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the two parameters (account_id, line_id). The description does not explain what these parameters mean or how they relate to the bank transaction. With no parameter descriptions in the schema and no compensation in the tool description, the agent cannot determine the correct values to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Détails d'une transaction bancaire' clearly indicates a read operation for a bank transaction, which aligns with the tool name get_payment. It specifies the resource (transaction bancaire) and implies a single item, distinguishing from list_payments. However, it does not explicitly differentiate from other payment-related tools like get_bank_reconciliation or get_bank_transactions, so a small deduction applies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites, such as obtaining account_id and line_id, or that this is the singular counterpart to list_payments. The agent is left to infer usage from the name and parameters, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Lister les ordres de fabrication' which implies a read-only list operation, but it doesn't mention pagination, default behavior, or what the response contains. It adds minimal value beyond the tool name and does not inform the agent about any side effects or return format.
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?
The description is a short, single sentence that is front-loaded and to the point. It earns its place by stating the core purpose, though it could be slightly more detailed. Its brevity is not a flaw, but it lacks supporting context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (list operation), the description is still incomplete. There is no output schema, and the description does not explain return values, filtering options, or any limitations. For a manufacturing order list, it fails to provide essential context like default ordering or how sqlfilters works.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'status' has a description). The description itself does not explain any of the three parameters (limit, status, sqlfilters) or how they affect the behavior. Since the schema coverage is low, the description was expected to compensate but does not, leaving the agent without parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Lister = list) and the resource (ordres de fabrication = manufacturing orders). It's unambiguous and distinguishes itself from other manufacturing order tools like create_ or get_ by indicating a list operation, though it doesn't explicitly mention any scope or filtering capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_manufacturing_order or produce_manufacturing_order. There is no mention of typical use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only restates the listing purpose without mentioning read-only nature, pagination, ordering, or any side effects. The added word 'configurés' gives marginal context but insufficient depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it essentially restates the tool name with minimal added information. It is under-specified rather than genuinely concise. It does not earn its place by providing useful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema and no annotations, the description should explain what is returned, how results are ordered, and how the limit parameter behaves. None of that is present, leaving the description incomplete for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'limit' parameter at all. Since the parameter's purpose is not explained anywhere, the description fails to compensate for the schema gap.
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 description clearly states the action ('Lister' = list) and the resource ('les modèles de notifications configurés' = configured notification templates), which is distinct from any sibling tool. It unambiguously identifies what the tool does and is not a mere tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, leaving the agent without decision-support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only states that a payment is recorded, but does not disclose whether the invoice status changes, how partial payments are handled, whether the payment is posted to accounting, or any side effects. This lack of transparency is a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy. It is front-loaded with the verb and object. However, given the tool's complexity (6 parameters, no output schema), the extreme brevity borders on under-specification rather than effective structure, so a 4 is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a minimal description, the tool is incomplete for practical use. The agent cannot infer the return value, the effect on the invoice, validation rules, or whether this tool is appropriate for the current context (e.g., customer vs supplier). It lacks essential context for a payment-recording operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must compensate by explaining parameter meanings. It fails to do so; it only refers generally to a payment on a supplier invoice without clarifying fields like 'datepaye', 'payment_mode_id', or 'accountid'. The description adds no value beyond the raw parameter names in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Enregistrer un paiement' (record a payment) and the resource 'facture fournisseur' (supplier invoice). It is specific and unambiguous. However, it does not explicitly distinguish from sibling tools like 'add_payment_to_invoice' (which likely operates on customer invoices), so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, nor any conditions under which this tool should be preferred over similar payment recording tools. The agent receives no contextual help for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It hints at a precondition ('validated') but fails to disclose side effects like sending emails to recipients, irreversibility, or behavior on invalid campaigns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence, which is concise. However, it is under-specified and lacks necessary details, making it less effective than a well-structured, slightly longer description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a sending action with likely side effects, no output schema, and no annotations, this description is incomplete. It omits return values, error scenarios, and the full meaning of 'validated'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning for the parameters 'id' or 'limit'. The schema documents 'limit' (max recipients, 0=tous), but 'id' is left completely unexplained, and the description does not compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Envoyer une campagne mailing validée' clearly states the action (send) and resource (mailing campaign), distinguishing it from siblings like create_mailing and get_mailing_stats. However, the qualifier 'validated' is not fully explained, which slightly weakens clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as create_mailing or get_mailing. The description does not mention prerequisites, exclusions, or related workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full responsibility. It only says 'validate' without explaining what validation entails (e.g., status change, finalization, side effects). The behavior remains opaque.
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?
The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a simple tool, though it lacks critical detail. This is conciseness without under-specification issues at the structural level.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no annotations, no output schema), the description is incomplete. It omits parameter semantics, behavioral effects, and usage context, leaving the agent with insufficient information to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines a single 'id' parameter but the description provides no explanation of its meaning (e.g., which id is expected). Schema description coverage is 0%, and the description does not compensate by describing the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Valider' = Validate) and the resource ('une fiche d'intervention brouillon' = a draft intervention form). It distinguishes from other validate_* tools by specifying the resource type, though it doesn't explicitly contrast with related intervention actions like close_intervention.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. It does not mention prerequisites (e.g., the intervention must be a draft), potential consequences, or situations where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral disclosure beyond the tool name. With no annotations, the agent lacks information about side effects, required permissions, or whether the order is created in draft or final state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, making it concise, but it essentially restates the tool name without adding semantic value. It lacks any structure or additional context that would make it more helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no output schema and no annotations, this description is insufficient. It does not mention what the function returns, whether the order is immediately validated, or any required process like adding order lines afterward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all parameters with 100% coverage. The description adds no additional meaning to the parameters, so the baseline score of 3 applies.
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 description 'Créer une commande fournisseur' clearly states the action (create) and the resource (supplier order), distinguishing it from sibling tools like create_order (customer order) and other supplier order operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as create_order or add_supplier_order_line. The description does not mention prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it only says 'get details' without explaining return format, error behavior (e.g., if ticket not found), or any access requirements. It does not state whether this is a read-only operation or what happens with missing IDs, leaving a significant gap.
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?
The description is a single, concise sentence that communicates the core purpose without extraneous words. It is appropriately sized for a simple read operation, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description is incomplete for a tool with one parameter. It fails to explain what details are returned (e.g., ticket status, messages, timestamps) or how errors are handled. While the tool is simple, a more complete description would clarify the response format and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines a single required 'id' parameter as a number, but with 0% schema description coverage, the description must compensate. It does not explicitly explain that 'id' refers to the ticket identifier, though this is somewhat inferable from the phrase 'ticket support'. The description adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Obtenir' = get) and resource ('les détails d'un ticket support' = details of a support ticket), making the purpose obvious. It implicitly differentiates from sibling tools like list_tickets (which lists all tickets) by implying retrieval of a single ticket's details, though it doesn't explicitly mention the ID parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention that it should be used for fetching a single ticket by ID rather than listing or creating tickets, nor does it reference any prerequisite conditions. The usage is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects, whether the initialization overwrites existing chart data, idempotency, required permissions, or return behavior. This is a significant omission for what appears to be a setup/mutation action.
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?
The description is a single concise sentence with no filler, making it easy to scan. The word 'Guide' adds slight ambiguity, but the structure is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a configuration/initialization tool with no annotations and no output schema, the description is far too sparse. It fails to explain what initialization entails, what conditions must be met, or what outcome the agent can expect, making it inadequate for safe invocation.
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?
The input schema is empty, so there are no parameters to document. Per the rubric, a 0-parameter tool receives a baseline of 4; the description adds no parameter-specific information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the verb 'initialiser' and the resource 'plan comptable SYSCOHADA' within Dolibarr, distinguishing it from list/get sibling tools. However, 'Guide pour' introduces slight ambiguity about whether the tool performs the initialization or merely provides instructions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus the many accounting configuration siblings (e.g., configure_accounting_*, get_chart_of_accounts). It does not mention prerequisites, sequencing, or alternative tools, so the agent receives no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the basic purpose without revealing any behavioral traits such as pagination, date filtering defaults, sorting, or whether it returns only non-reconciled entries. The description adds no insight beyond the tool's name.
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?
The description is a single, concise sentence with no wasted words. It is front-loaded and easy to read, though it is minimal. This brevity is appropriate for a simple list tool, but it sacrifices detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter descriptions, the description is completely inadequate. It fails to explain what the entries are, how date filters behave, what limit does, or what the response contains. The description provides no contextual information to help an agent use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not mention the parameters (limit, date_end, date_start) at all. It fails to compensate for the lack of schema descriptions, leaving the semantics of these parameters entirely unexplained.
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 description clearly states the action and resource: 'List the accounting entries of the general ledger.' This is specific and distinguishes it from sibling tools like list_accounting_accounts (accounts), list_accounting_journals (journals), and export_accounting_entries (export).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives such as get_trial_balance or get_financial_summary, nor does it explain typical use cases, prerequisites, or scenarios where this tool is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'List supplier receipts.' It does not disclose pagination behavior, status filter semantics, sqlfilters usage, response format, or whether any side effects occur, leaving most behavioral expectations unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no wasted words, but it lacks any structured context or elaboration. It is efficient but borderline under-specified for a tool with multiple parameters and no other documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list operation with four optional parameters, no annotations, and no output schema, the description only provides the basic purpose. Important contextual information such as pagination behavior, status filter options, and result structure is entirely absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has four parameters (page, limit, status, sqlfilters) with 0% description coverage, and the description does not explain any of them. The agent is left to infer the meaning of status codes or SQL filter syntax, so the description adds no value to parameter understanding.
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 description uses a specific verb 'Lister' and a specific resource 'réceptions fournisseurs' (supplier receipts), clearly identifying it as a list operation. It is unambiguous and naturally distinguished from the singular get_reception sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as list_shipments or get_reception, nor does it mention any exclusions or filtering context. It states only the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only says 'list', implying a read operation, but does not disclose pagination, authentication requirements, or whether it returns all records by default.
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?
The description is concise and front-loaded, consisting of a single, clear sentence. However, it is almost too sparse, but no wasted words exist.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and minimal parameter descriptions, the description is inadequate for a 4-parameter tool. It does not explain return values, filter semantics, or status meanings, making it difficult for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'status' has a description), and the tool description provides no parameter information at all. It fails to clarify the meaning or usage of limit, user_id, or sqlfilters.
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 description clearly states the tool lists salary slips/payslips ('Lister les fiches de paie/salaires'). The verb 'Lister' (list) and resource are specific, and it is distinct from sibling tools like get_salary and create_salary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, or what filtering capabilities exist (e.g., limit, status). The description is purely functional without contextual use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without revealing side effects, idempotency, reversibility, required permissions, or what happens if the line is already reconciled. This is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no fluff, which aids quick reading. However, it is under-specified given the tool's complexity, so while concise, it sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with three required parameters and no output schema or annotations, yet the description provides only the basic action. Missing are return value, prerequisites, and the meaning of num_releve beyond the schema. The description is inadequate for an agent to use the tool correctly in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes only num_releve with an example, leaving account_id and line_id as bare numbers. The description does not compensate, as it fails to explain the meaning or purpose of any parameter. The 33% schema coverage is not offset by any parameter-related context in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Marquer une ligne bancaire comme rapprochée' clearly states the action (mark as reconciled) and the resource (a bank line). It is specific enough to distinguish from sibling tools like get_bank_reconciliation, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as get_bank_reconciliation or add_bank_transaction. The usage is only implied by the verb, with no mention of prerequisites, conditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It indicates a configuration action, but does not mention side effects, whether existing mappings are overwritten, required permissions, or any confirmation behavior. The word 'Guide' may also imply documentation rather than an executable action.
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?
The description is a single concise sentence with no redundant words. It is front-loaded with the core purpose. However, it is so minimal that it lacks detail, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it is a configuration/set tool with no output schema, no annotations, and zero parameter descriptions, the description is insufficient. It does not cover return values, error conditions, or the effect of the operation, making it hard for an agent to fully predict behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 gives examples for account_number (411, 4431, 706) but leaves account_type completely unexplained and does not clarify the relationship between the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures default accounting accounts, with examples like 411 and 706. The verb 'configurer' and resource are present, but it doesn't strongly differentiate from sibling configuration tools such as configure_vat_mode or configure_accounting_export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are no exclusions, prerequisites, or references to other tools. An agent would have to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It merely says 'Ajouter' without mentioning that it mutates the intervention, whether it requires an existing intervention, or what the response looks like. This is a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise, though it could have included a short clause with usage guidance without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter mutation tool with no output schema and no annotations, this description is drastically under-specified. It lacks any behavioral details, prerequisites, return information, or relation to the intervention lifecycle, making it inadequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes 8 parameters with 88% coverage, including units and examples, so the description isn't required to add parameter details. The phrase 'ligne de temps' hints at the temporal nature (duree, qty), but no extra meaning is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Ajouter') and the resource ('une ligne de temps à une fiche d'intervention'), distinguishing it from other line-add tools by targeting interventions. However, it doesn't elaborate on what a 'ligne de temps' specifically entails beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool, what prerequisites exist (e.g., the intervention must already exist), or any alternatives. The description only states the action, leaving the agent to infer context from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral implications. It merely repeats the verb 'approve' without explaining side effects (e.g., status change, notifications), permissions required, reversibility, or response behavior.
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?
The description is a single, efficient sentence. It states the purpose without wasted words. However, it lacks additional structure or detail that could make it more helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description is minimal. Without annotations or an output schema, the agent cannot understand the full impact of approval or the workflow context. The description alone is insufficient for reliable usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'id' with 0% description coverage. The description does not specify what 'id' refers to or how it should be obtained. While inferable from context, the description provides no explicit parameter semantics.
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 description 'Approuver une demande de congé' clearly states the action (approve) and the resource (leave request). It distinguishes from sibling tools like refuse_leave_request, create_leave_request, and list_leave_requests, which have different verbs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, workflow position, or conditions for approving a leave request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only says 'create draft supplier invoice,' which implies a draft state but does not disclose permissions, side effects, or return behavior. This is insufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no wasted words. It is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 6 parameters, the description is far too minimal. It does not explain required fields (socid), optional fields, or the workflow for building a draft invoice, such as adding lines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters. The schema covers 50% of parameters with descriptions, but the description adds no additional meaning or guidance for the undocumented ones (note_public, cond_reglement_id, mode_reglement_id).
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 description states a specific verb ('Créer' = create) and a resource ('facture fournisseur' = supplier invoice), and adds the 'brouillon' (draft) qualifier, distinguishing it from validation and line-adding tools. This makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus related tools like validate_supplier_invoice or add_supplier_invoice_line. There is no mention of workflow context, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'create a support ticket,' which implies a write operation, but does not explain side effects (e.g., whether a confirmation is sent, if the ticket is immediately visible, or any permissions required). The description adds minimal value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short—only four words—which makes it concise but under-specified. It lacks any elaboration that would help the agent use the tool effectively, and while it is front-loaded, it does not earn its place by providing meaningful guidance beyond the tool's name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters) and the absence of annotations and output schema, the description is insufficiently complete. It fails to mention return values, assumptions, or any usage context that would help an agent know when to invoke this tool and what to expect from it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 7 parameters with descriptions, achieving 100% schema_description_coverage. Since the structured schema already explains each parameter, the description does not need to repeat them; however, it also provides no additional context or clarification beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Créer un ticket support' clearly states the verb (create) and resource (support ticket), distinguishing it from sibling tools like list_tickets, get_ticket, add_ticket_message, and close_ticket. It is specific enough to identify the tool's primary function, though it lacks any additional context about the ticket creation workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as add_ticket_message or assign_ticket. The description does not mention prerequisites, exclusions, or when to prefer a different tool, leaving the agent to infer usage from the schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It only lists the metrics (CA, orders, quotes) and temporal grouping, but does not state whether the operation is read-only, what permissions are required, the response format, or how missing periods are handled.
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?
The description is a single concise sentence with no redundant wording. It directly conveys the core function and is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must explain return structure and edge cases. It does not describe whether the result is a list or summary, units for CA, or handling of empty periods. This is inadequate for an analytics tool and leaves many gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 2 parameters; month has a description (1-12, optional) but year has none. The description's 'par mois/année' hints at temporal grouping but does not clarify whether year is required, valid ranges, or the effect of omitted parameters. This adds minimal value beyond the schema, which already covers month but not year.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: providing activity statistics (CA, orders, quotes) aggregated by month/year. This distinguishes it from siblings like get_mailing_stats or get_financial_summary. However, it is a noun phrase without an explicit verb (e.g., 'retrieves'), which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling list contains many analytics tools (e.g., get_financial_summary, get_vat_report), and the description does not mention preferred contexts, exclusions, or contrast with similar functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, leaving the description to carry the burden. It only restates that the tool gets details, with no mention of read-only behavior, required permissions, response format, or side effects. The description adds little beyond the tool name's implication.
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?
The description is a single short sentence that directly conveys the purpose without unnecessary words. It is front-loaded and appropriately sized for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description is incomplete. It doesn't explain what details are returned, what the response looks like, or when this tool is appropriate. The absence of usage and behavioral information leaves the agent guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines 'id' as required number with 0% description coverage. The description does not clarify that this is the supplier invoice ID or provide any additional meaning. The parameter's purpose is inferred solely from the tool name, which is insufficient support.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Obtenir les détails d'une facture fournisseur' (get supplier invoice details), clearly identifying the action and resource. However, it doesn't distinguish from related tools like get_invoice or list_supplier_invoices, lacking specific scope or uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description provides no context for selecting this tool over other invoice or getter tools, and no exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the literal function. It does not mention whether the operation is read-only, how filtering works, what the response contains, or any side effects.
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?
The description is a single concise sentence that is front-loaded and contains no fluff. It has a clear verb-object structure, though it is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter explanations, the description is incomplete. It does not describe return values, filtering/pagination behavior, or the meaning of the parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes 3 parameters (limit, sqlfilters, thirdparty_ids) with zero description coverage. The description does not explain any parameter semantics or provide examples, leaving the agent to infer meaning solely from parameter names.
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 description clearly states the tool lists deposit invoices (customer advances) using a specific verb and resource. It distinguishes itself from sibling tools like list_invoices and list_payments by specifying 'factures d'acompte' (deposit invoices).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_invoices or create_deposit. The description only states the function without any context, exclusions, or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only adds the scope 'received' but does not mention return format, pagination, authentication needs, or whether the operation is read-only. For a list operation, this leaves the agent guessing about the tool's behavior.
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?
The description is a single, front-loaded sentence with no unnecessary words. The word 'reçus' (received) adds value by specifying the subset of donations. It is appropriately concise, though it could be enhanced with parameter information without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter descriptions, the description is far too sparse to be complete. It does not address the three parameters, default behavior, pagination, or the structure of the response. An agent would need to infer too much to use this tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for its three parameters (limit, status, sqlfilters), and the description does not explain any of them. The agent receives no information about what these parameters do, how they affect the results, or acceptable values, which is a significant gap.
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 description clearly states the verb 'Lister' (list) and the resource 'dons/donations reçus' (received donations), which distinguishes it from sibling tools like get_donation (single item) and create_donation (creation). The addition of 'received' narrows the scope effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_donation or other list tools. It does not mention filtering contexts, how to combine with other tools, or when a different tool would be more appropriate. The description only states the action without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action (listing payments received) and does not reveal any side effects, filtering behavior, pagination, or safety characteristics beyond what is implicit in a 'list' operation.
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?
The description is a single, concise sentence in French. It is front-loaded with the main action and resource, and every word adds meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the description provides insufficient context. It does not mention what the response contains, how parameters affect the results, or the default behavior (e.g., account_id default of 1), leaving the agent without essential operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only account_id has a description), yet the description adds no parameter information. It indirectly hints at the account parameter via 'compte bancaire' but does not explain limit, date_start, date_end, or reconciled_only, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lister') and the resource ('transactions d'un compte bancaire') with a clarifying scope ('paiements reçus'). It is specific and understandable, but it does not explicitly distinguish itself from the sibling tool get_bank_transactions, which also lists bank transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description only states what the tool does, without mentioning exclusions, prerequisites, or situations where another tool would be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It merely states the action without explaining filtering, authentication, return format, or pagination, leaving the agent without expectations.
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?
The description is a short, front-loaded phrase with no waste. However, it may be too underspecified to be a fully helpful tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema or parameter documentation, the description is insufficient for an agent to use the tool confidently. It lacks details on return values and query structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, and the description does not explain any of the three parameters (limit, sqlfilters, thirdparty_id). No compensation for the missing schema info.
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 description uses a specific verb ('Lister') and resource ('factures fournisseurs payées'), clearly indicating it lists paid supplier invoices. This distinguishes it from sibling tools like list_supplier_invoices (all supplier invoices) and list_payments (payments).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to prefer this over list_supplier_invoices or how it relates to list_payments, leaving the agent without explicit selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of disclosing behavior. It only provides status code meanings (0=Nouveau, 1=En cours, 3=Suspendu, 5=Fermé), which are parameter value semantics rather than tool behavior. It does not mention pagination, default limits, sorting, or side effects. The read-only nature is implied but not explicit.
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?
The description is one concise sentence plus a status mapping. Every element earns its place; the status code list adds practical value without redundancy. It is front-loaded with the primary action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and five optional parameters, the description is insufficient for an agent to fully understand the tool's capabilities. It omits return value behavior, pagination handling, filter syntax, and the meaning of most parameters. The minimal text leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with five parameters, so the description must compensate. It adds meaning only for 'status' by mapping codes to labels, which is helpful. However, it leaves 'page', 'limit', 'sqlfilters', and 'thirdparty_id' completely unexplained, so it only partially addresses the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Lister les tickets support' (List support tickets), which clearly identifies the action (list) and resource (support tickets). This distinguishes it from sibling tools like get_ticket, create_ticket, and close_ticket. However, it lacks any scope or filtering nuance that would differentiate it from other list tools, so it doesn't earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It doesn't mention whether to use get_ticket for single-ticket details or how to combine filters. No exclusions or prerequisites are stated, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'modify', which implies a mutation, but does not specify whether updates are partial or full, what happens if the ID does not exist, or what the return value is. This is insufficient for a write operation.
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?
The description is a single, front-loaded sentence that directly states the action and resource. It contains no unnecessary words, though the trailing 'etc.' is slightly vague but acceptable for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the description is too terse to provide adequate context. It fails to explain the update semantics (partial vs. full), required fields beyond id, or the response format. This mirrors the update_drive example, which also scored a 2.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (4 of 6 parameters have descriptions). The description adds minimal value beyond the schema—it lists 'price, description, status' as examples but does not explain the 'label' parameter or clarify that only provided fields are updated. It does not compensate for the missing parameter descriptions and lacks specificity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'modifier' (to modify) and the resource 'produit existant' (existing product), and it lists common editable fields (price, description, active status). This distinguishes it from create_product and get_product, but it does not explicitly differentiate it from update_product_stock or set_product_price, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling tools. It does not mention alternatives like update_product_stock or set_product_price, nor does it state any prerequisites or exclusions. The agent is left to infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects or constraints. It merely states the action without mentioning validation, recalculation, or whether the order must exist. This is a minimal 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and free of fluff. It is concise, though it is minimal in content. It earns its place by stating the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and no annotations. The description only captures the basic action, leaving out any information about return values, side effects, or operational context. This is insufficient for a mutation tool in a large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the description adds no parameter details. Required parameters like qty and tva_tx are left to be inferred from names, and tva_tx is non-obvious. The description does not compensate for the schema gaps.
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 description clearly states the action (add a line) and the target (supplier order). It distinguishes from sibling tools like add_order_line (customer orders) and add_supplier_invoice_line (supplier invoices) by specifying 'commande fournisseur'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The only context is implicit in the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only states the action without explaining effects like status changes, permissions, requester notification, or irreversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it under-specifies. It is not as tautological as 'Process', but it lacks essential context, so it is not exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and a minimal description, the description is inadequate. It does not explain what happens when the ticket is closed, return values, or any side effects, even though the tool itself is simple.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'id' with 0% description coverage, and the description does not mention the parameter at all. It fails to compensate for the missing schema documentation, though the parameter name is somewhat self-explanatory.
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 description 'Fermer un ticket support' clearly identifies the action (close) and the resource (support ticket), distinguishing it from sibling tools like create_ticket, assign_ticket, and get_ticket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., ticket must exist), nor when closing differs from assigning or resolving.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It does not disclose the side effects of configuration (e.g., whether it modifies settings, overwrites existing config, requires permissions, or is reversible). The word 'Guide' is vague about whether the tool performs an action or merely instructs.
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?
The description is a single concise sentence, front-loaded with the key purpose. No useless filler, and the format examples earn their place. However, it is arguably too brief given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, this description is far from complete. It lacks parameter explanations, expected behavior, prerequisites, and return values, making it hard for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 adds meaning only for 'format' by listing examples (FEC, Sage, Cegid), but leaves 'separator', 'date_format', and 'export_model' entirely unexplained. This is insufficient for an agent to know how to fill these fields.
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 description states a specific verb ('configurer') and resource ('export comptable'), naming example formats (FEC, Sage, Cegid). It clearly distinguishes from sibling 'export_accounting_entries' which likely performs the actual export, whereas this tool configures it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'export_accounting_entries' or 'configure_accounting_autolettering'. The description implies configuration use-case but gives no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full behavioral disclosure. It only states 'create a mailing campaign'; it does not disclose whether the campaign is saved as draft, whether it is sent immediately, what side effects occur, or what authentication/permissions are needed. Creation implies mutation but lacks necessary context.
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?
The description is a single, focused sentence with no filler or redundancy. However, its extreme brevity limits the information conveyed, so it is efficient but not maximally useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations, so the description is the only source of context. It omits return values, expected parameter format (e.g., HTML body), and the lifecycle relationship to send_mailing. For a creation tool with five parameters, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one of five parameters (body) has a schema description, and the tool description adds no parameter information. It does not explain the meaning of title, subject, from_name, or from_email, nor clarify required fields beyond the schema's required list. With low schema coverage (20%), the description should compensate but does not.
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 description names a specific action ('Créer' = create) and resource ('campagne mailing' = mailing campaign), distinguishing it from sibling tools like send_mailing, list_mailings, or get_mailing. It clearly indicates the tool creates a new mailing campaign rather than sending or retrieving one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., send_mailing, list_mailings). It does not mention workflow prerequisites, such as needing to create before sending, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'create a task in a project' without mentioning side effects, required fields, permissions, or return behavior. For a mutating operation, this is a significant transparency gap.
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?
The description is a single, clear sentence with no superfluous words. It is front-loaded with the core action and resource. It is appropriately sized for a straightforward create operation, though it sacrifices usage guidance for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters and no output schema, the description is too minimal to be contextually complete. It does not explain what happens upon creation, how to structure required inputs, or what to expect in response. The rich schema compensates for parameter details but not for overall workflow context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all 9 parameters, so schema coverage is 100%. The description adds no additional parameter semantics beyond what the schema offers. It does not clarify parameter formats, defaults, or relationships beyond the existing field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Créer une tâche dans un projet' clearly states the action (create) and resource (task) with a scoping detail (in a project). It distinguishes the tool from other create tools like create_agenda_event or create_ticket, but does not explicitly differentiate from all siblings. The core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_agenda_event or list_tasks. It neither states prerequisites, typical scenarios, nor exclusions. Users must infer usage from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the state change to 'delivered'. It does not disclose whether the shipment must be validated first, whether date_delivery defaults to today, whether the action is reversible, or any permission requirements. For a mutation tool this is a significant gap.
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?
The description is a single, front-loaded sentence with no filler words. It is concise, but so terse that it omits useful operational context that could be included without much added length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a status-mutation tool with no annotations and no output schema, the description leaves out preconditions, default behaviors, and consequences. It is minimally viable but incomplete for an AI agent to invoke correctly, especially within a workflow of shipment-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a description for date_delivery but none for id, giving 50% schema coverage. The tool description adds no parameter details at all, failing to compensate for the missing id semantics; the id's meaning is only inferable from the tool name.
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 description clearly uses a specific verb ('Marquer') and resource ('expédition'), indicating the action of marking a shipment as delivered. This distinguishes it from sibling tools like create_shipment, validate_shipment, and get_shipment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as validate_shipment or create_shipment. It does not mention workflow position, prerequisites, or exclusions; usage is only implied by the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 does not mention that this is a read-only operation, what the output format looks like, whether it returns per-customer details or totals, or any prerequisites. The only hint is the name 'get', which implies read-only, but no additional context is given. This is insufficient for a tool with zero annotation support.
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?
The description is a single, concise sentence that directly states the core function and the aging buckets. It is front-loaded with the essential information and contains no filler or redundant wording. Every word serves the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, no annotations, and a simple parameter set, the description should compensate by explaining the return structure or the meaning of the aging buckets. It does not. An agent would not know if the tool returns a list of customers, aggregated amounts, or a report object. The description covers only the basic concept, leaving significant gaps for invocation and result interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides complete coverage for the single 'type' parameter with a description ('customer' ou 'supplier'), so the baseline is 3. The tool description does not add any extra meaning about the parameter; it actually uses 'clients' in the description, which could be confusing since the parameter accepts both customer and supplier. However, since the schema is self-sufficient, the description need not elaborate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning an aged customer balance with specific aging buckets (0-30j, 31-60j, 61-90j, +90j). The verb is implied by the name 'get', and the resource is well-specified. However, it mentions only 'clients' while the schema supports both 'customer' and 'supplier', which slightly narrows the scope and misses the opportunity to distinguish from other reports like get_customer_statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply states what the report contains, but does not mention if it should be used for customer aging, supplier aging, or how it differs from other accounting tools like get_trial_balance. There are no exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. 'Obtenir' implies a read-only operation, but the description adds no context about authentication requirements, error behavior, return format, or side effects. Minimal transparency beyond the inferred read operation.
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?
The description is a single, succinct sentence that directly conveys the tool's action. It is front-loaded with the key information and contains no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter retrieval tool, the description covers the basic purpose. However, with no output schema and no parameter details, it lacks information about the returned object structure or potential edge cases. It is adequate but leaves room for more helpful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'id' (number) with zero description coverage. The tool description does not clarify that 'id' refers to the donation ID or provide any additional meaning. The agent must infer the parameter's purpose from the tool name and naming conventions, which the description does not compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Obtenir les détails d'un don' uses a specific verb (obtenir) and resource (détails d'un don), clearly indicating retrieval of donation details. It implicitly distinguishes from siblings like list_donations and create_donation by focusing on a single donation, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_donations or create_donation. It only states what the tool does, without any context about prerequisites, exclusions, or scenarios for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only states the basic action. It does not explicitly confirm read-only behavior, error handling if the ID is not found, permissions required, or what 'details' are included in the response.
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?
The description is a single short sentence that is front-loaded with the action. It is appropriately concise for a simple getter tool, though it omits any additional context that could be included without bloating.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally viable for a simple get-by-ID tool, providing enough to understand the basic purpose. However, with no annotations, no output schema, and zero parameter coverage, it leaves gaps about the exact return content and edge cases, making it only adequate, not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'id' parameter at all. Although the parameter is self-explanatory, the description adds no semantic value to clarify its purpose, format, or usage.
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 description uses a specific verb 'Obtenir' (get) and resource 'détails d'une fiche d'intervention', clearly distinguishing it from sibling tools like list_interventions, create_intervention, and close_intervention. The action and target are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply states the action without mentioning prerequisites, such as needing an intervention ID, or scenarios where list_interventions would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the high-level purpose. It does not disclose whether the operation is read-only, what response format to expect, or any potential errors or permissions. The word 'obtenir' implies retrieval but adds little beyond the tool name.
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?
The description is a single concise sentence that is easy to parse. No unnecessary words or repetition. However, it is somewhat under-specified, which prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool, the description is minimally acceptable but lacks detail. It does not specify that the response is a full mailing object, nor does it mention the required ID parameter. The absence of an output schema increases the need for clarity, but the description provides only vague 'details'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'id' (number) with no description, and schema description coverage is 0%. The description does not explain the meaning or purpose of 'id' (e.g., that it is the mailing campaign ID). This is a significant gap since the description must compensate for the schema's lack of parameter details.
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 description 'Obtenir les détails d'une campagne mailing' clearly states the action (get details) and resource (mailing campaign). It effectively distinguishes from siblings like list_mailings (which lists campaigns) and get_mailing_stats (which gets statistics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It does not mention that it retrieves a single campaign by ID nor when to prefer list_mailings or get_mailing_stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only lists the metrics 'sends, errors' but does not state that the operation is read-only, describe the response format, or mention any side effects or prerequisites. The noun-phrase description implies a read operation but does not confirm it.
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?
The description is a single short phrase that contains no redundant words. It efficiently conveys the resource (campaign) and key metrics (sends, errors), making it appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description must fully explain the tool's behavior and return values. It only mentions 'sends, errors' without detailing the structure of the statistics, whether the response is a single object or list, or any additional context. The tool is simple, but the description is too scant to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines a required 'id' of type number with no description, and schema coverage is 0%. The description partially compensates by indicating that the id corresponds to a campaign ('d'une campagne'), giving some context. However, it does not explicitly map id to a campaign ID or explain any format constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Statistiques d'une campagne (envois, erreurs)' clearly indicates the tool retrieves statistics for a specific mailing campaign, including sends and errors. It distinguishes itself from sibling tools like get_mailing by focusing on aggregate stats rather than campaign details, though it lacks an explicit verb like 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_mailing or list_mailings. The description does not mention exclusions or alternative tools, leaving the agent to infer the tool's role solely from its name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It only says 'get details', which implies a read operation, but does not disclose any additional behavioral traits such as what happens if the order is not found, what fields are returned, or any permission requirements. This is a minimal level of transparency for a getter that has no output schema.
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?
The description is a single, concise sentence that is front-loaded with the core action and resource. Every word is necessary, and there is no extraneous information or repetition. It is an ideal example of minimalism without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one parameter and no output schema. The description is enough to understand the basic purpose, but it lacks information about the return structure and potential error cases. Given the low complexity, a score of 3 reflects that it is minimally viable but not fully complete, especially without any annotation support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining the 'id' parameter or its format. The parameter is a simple numeric ID, which is self-explanatory, but the description adds no meaning beyond what the schema already provides. For a low-coverage case, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get details) and the resource (a manufacturing order), using the specific verb 'obtenir' and the resource 'un ordre de fabrication'. It is distinct from list_manufacturing_orders, though it does not explicitly mention that distinction. The purpose is immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like list_manufacturing_orders or get_order. There is no mention of prerequisites, such as needing the order ID, or any context where this tool is preferred. The agent is left without explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states that it gets details, without mentioning error behavior, required permissions, or response structure. The word 'details' adds minimal context beyond the tool name.
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?
The description is a single concise sentence in French, with no redundant words. It is efficiently front-loaded and every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but the description is very thin: no output schema, no annotations, and no clarification of what 'details' contains. It also lacks guidance on how to obtain the id (e.g., via list_salaries). Given the low complexity, a slightly richer description is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'id' with no description (0% coverage), and the description does not mention the parameter at all. It fails to clarify what 'id' refers to, leaving the agent to infer it is the salary id without any confirmation.
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 description clearly states the verb 'Obtenir' (get) and the resource 'fiche de salaire' (payslip), indicating a retrieval operation for a specific salary record. This distinguishes it from sibling tools like list_salaries and create_salary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it fetches a single record by id, nor does it suggest pairing with list_salaries to obtain the id. There is no contextual instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the obvious read operation without describing return format, potential errors, or whether any side effects occur.
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?
The description is a single clear sentence with no redundant content. It is concise and front-loaded, though somewhat sparse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should at least indicate what shipment details will be returned, but it does not. The schema is minimal (one id), so the tool is simple, but the absence of return information leaves a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'id' with 0% schema description coverage, and the tool description does not explain that 'id' refers to the shipment identifier or how to obtain it. The description adds no semantic value beyond the parameter name.
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 description 'Obtenir les détails d'une expédition' uses a specific verb ('Obtenir') and resource ('détails d'une expédition'), clearly indicating it retrieves shipment details. This distinguishes it from sibling tools like list_shipments, create_shipment, or deliver_shipment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as list_shipments or get_reception. It does not mention prerequisites, such as needing an existing shipment ID or how to find one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses one behavioral trait: the trial balance is computed from invoices if the chart of accounts is not initialized. However, it omits other important behavior such as how date parameters affect the output, the format of the response, and whether the operation is read-only.
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?
The description is extremely concise, consisting of two short sentences in French. It front-loads the core purpose and adds one relevant conditional detail. No redundant wording or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite its simplicity, the tool has two date parameters and no output schema, and the description fails to explain the parameters, return value, or how this report differs from related accounting reports. For an agent deciding among many sibling tools, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, but it does not explain the date_start and date_end parameters at all. The description adds no meaning to these parameters, leaving the agent without any information about date filtering or required inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing the general balance of accounts (trial balance), a specific accounting resource. It adds a computational condition (calculated from invoices if chart of accounts is not initialized), which gives some scope but does not distinguish it from sibling accounting report tools like get_financial_summary or get_aged_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The conditional note about calculation from invoices is behavioral, not a usage recommendation, and there is no mention of prerequisites, preferred contexts, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description does not disclose any behavioral traits such as read-only status, permissions, or response format. The noun-phrase description ('Rapport de déclaration TVA...') does not even explicitly state that the tool returns a report, leaving the agent to infer from the name. This is a significant gap for a tool with no annotations.
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?
The description is a single compact sentence with no redundant information. It is front-loaded with the key concept (VAT declaration report) and includes the main differentiator (collected vs deductible). This is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (two parameters, no output schema), and the description covers the core purpose. However, it omits behavioral details like read-only nature, exact return contents, and any conditions; these are not covered by annotations or output schema. It is minimally viable but has clear gaps, especially given the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents month as 'Mois 1-12 (si vide = année entière)', but year has no description. The description only mentions 'pour une période' without explaining the required/optional nature of parameters or their formats. It fails to compensate for the missing year description, so the description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as producing a VAT declaration report for a given period, with a breakdown between collected and deductible VAT ('collectée vs déductible'). It distinguishes from sibling tools like get_trial_balance by focusing specifically on VAT reporting. However, it lacks an explicit verb like 'retrieves' or 'returns', relying on the tool name 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternative accounting/reporting tools. It does not mention any exclusions, prerequisites, or comparisons with siblings such as get_trial_balance or get_financial_summary. The description only names the report without situational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the function without detailing return format, error handling, or permissions. The read-only nature is implied but not explicitly disclosed.
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?
The description is a single short sentence with zero wasted words. It is front-loaded and appropriately sized for the simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a single parameter, the description is minimal but does not convey the response structure or any usage-specific context. For a simple get-by-id tool, it is barely adequate but lacks depth beyond the tool name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'id' parameter at all. The tool simply says 'get warehouse details' without explaining that the id parameter identifies which warehouse, leaving the agent to infer it from the schema alone.
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 description 'Obtenir les détails d'un entrepôt' clearly states the action (get) and resource (warehouse details), distinguishing it from siblings like list_warehouses and get_warehouse_stock. It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_warehouses or get_warehouse_stock. No context or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description does not disclose behavioral traits beyond the basic listing action. It does not mention whether the result is read-only, how results are ordered, whether pagination is applied, or any side effects. For a tool without annotations, this is insufficient behavioral transparency.
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?
The description is extremely concise, using a single short phrase without unnecessary words. It is front-loaded and easy to parse. However, it is so brief that it omits valuable differentiators and context, making it more under-specified than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of the closely related sibling tool 'list_expense_reports', the description does not explain the relationship or unique role of 'list_expenses'. There is no mention of the output format or any constraints. The description is incomplete for an agent to confidently select this tool over alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add any information about parameters. The schema covers two of three parameters ('status' and 'user_id') with descriptions, but 'limit' is left undocumented. With 67% schema coverage, the description could compensate for the missing 'limit' explanation but does not. This results in a moderate score, as the schema carries most of the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Lister' = list) and a resource ('notes de frais' = expense reports), clearly indicating the tool's function. However, it does not distinguish this tool from the sibling tool 'list_expense_reports', which likely has an overlapping purpose, so it misses the opportunity to differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'list_expense_reports' or other listing tools. It does not mention filtering capabilities, typical use cases, or any exclusions. This leaves the agent uncertain about the appropriate context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only reveals the meaning of status codes, but does not explain pagination behavior, default limits, output format, or any side effects. For a read-only list operation, this is minimal information.
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?
The description is a single concise sentence with an equally concise status legend. It is front-loaded with the main purpose and the status codes are directly relevant to a common filter. No filler words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no annotations, and no output schema, so the description must provide substantial context. It only covers status values, leaving pagination, filtering, and return structure entirely unexplained. The agent would have to guess about pagination and response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It explains the status parameter by mapping numeric values to human-readable states, but it does not explain the other four parameters (page, limit, sqlfilters, thirdparty_id). This partial coverage is insufficient for full parameter understanding.
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 description clearly states the action and resource: 'Lister les fiches d'intervention' (List intervention sheets). This is a specific verb+resource pair that distinguishes it from sibling tools like get_intervention (retrieve a single intervention) and create_intervention (create a new one).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that get_intervention is for retrieving a single record or that other list tools exist. The status code legend gives some filtering context but does not clarify usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It only states the list action and status codes, without disclosing return format, pagination behavior, default limits, or any side effects. This is minimal behavioral context for a list operation.
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?
The description is concise and front-loaded with the tool's purpose. However, the status mapping duplicates schema information and introduces a mismatch, making it less clean than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description should explain the return value and filter usage. It does not mention what the tool returns or how sqlfilters work, leaving significant gaps for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The status mapping is repeated but inconsistent: the description says status 2='En cours' while the schema says 'Expédiée'. Page, limit, and sqlfilters are not explained in the description, and schema description coverage is only 25%, so the description fails to compensate for the low coverage.
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 description clearly states 'Lister les commandes clients' (list customer orders), specifying the action (list) and resource (customer orders). This distinguishes it from siblings like get_order (single order) and list_supplier_orders (supplier orders).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_order for a single order or list_invoices for invoices. The status enum hints at filtering but does not explain scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it only states the action. It does not describe pagination, default limits, status handling, or the structure of the returned project list, leaving significant 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundant details. It is front-loaded and easy to parse, earning a perfect score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with four optional parameters and no output schema, the description is too minimal. It does not mention how the tool handles status, sqlfilters, or the return format, nor does it provide selection context among the many sibling list tools. This leaves the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes status and thirdparty_id, but limit and sqlfilters are undocumented. The description adds no parameter information, so it does not compensate for the 50% coverage gap. However, the existing schema descriptions are clear, so this is an adequate baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lister les projets Dolibarr' clearly states the tool lists Dolibarr projects, which is a specific verb+resource combination. It distinguishes itself from the singular get_project sibling by virtue of the plural 'list', though it does not explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_project or other list tools. There is no mention of filtering, pagination, or exclusions, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state that this is a read-only operation, does not describe the return format or pagination behavior, and provides no information about potential side effects or limitations. The description is purely a statement of intent without any behavioral context.
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?
The description is very concise, consisting of a single short phrase. It is front-loaded and wastes no words. However, it is arguably too sparse, providing little additional value beyond the tool name. Still, for conciseness, it is appropriately sized for a simple list operation, though it sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is incomplete. It does not explain what the returned list contains, how to use the 'limit' or 'sqlfilters' parameters, or any default behavior (e.g., status defaults to active). The description alone is insufficient for an agent to use the tool correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 33% (only 'status' has a description). The description itself adds no parameter information, leaving 'limit' and 'sqlfilters' unexplained. While the schema partially documents 'status', the lack of compensation in the description for the other parameters results in insufficient parameter semantics.
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 description clearly states the tool's function: 'Lister les entrepôts/dépôts de stock' (list warehouses/stock depots). It uses a specific verb (list) and resource (warehouses), and the distinction from sibling tools like get_warehouse (retrieve a single warehouse) and create_warehouse (create a warehouse) is evident from the verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any filtering options, default behavior, or relationships to other warehouse-related tools. There is no context about when listing is appropriate or when one should use get_warehouse instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the outcome (mark as produced) but does not explain side effects, such as whether stock is updated, whether the operation is reversible, or whether it triggers any downstream processes. This lack of context is a significant gap for a state-transition tool.
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?
The description is a single concise sentence in French, front-loaded with the action verb. It is appropriately brief, though it could be slightly more informative without losing conciseness. No wasted words, but also no extra value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, no annotations, and no output schema, the description is too sparse. It fails to mention prerequisites (e.g., order must be validated first), consequences (e.g., stock impact), or what happens to the order after marking. Sibling tools suggest a workflow, but the description does not explain where this step fits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information. The schema covers 50% of parameters (qty has a description, id does not), but the description does not compensate for the undefined 'id' parameter. It does not clarify that 'id' refers to the manufacturing order ID, nor does it explain any constraints on 'qty' beyond what the schema already says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: mark a manufacturing order (OF) as produced/finished. It distinguishes itself from siblings like validate_manufacturing_order by specifying the production completion step. However, the abbreviation 'OF' is not expanded, which slightly reduces clarity for users unfamiliar with French manufacturing terminology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: it is used to mark production as finished, likely after a manufacturing order has been validated. However, there is no explicit guidance on when to use this versus validate or other related tools, nor any mention of prerequisites or alternatives. The description relies on the user inferring the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'irréversible' (irreversible), which is a key behavioral trait, but the phrase is incomplete ('sans avoir') and lacks context. It does not disclose side effects like stock movements via idwarehouse, permissions, or post-validation status changes, leaving significant gaps in behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, which is generally good, but it is truncated and grammatically incomplete ('sans avoir'). This undermines clarity and makes it seem unpolished. A complete sentence would be more effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool performs a critical state transition with potential side effects (e.g., stock movements via idwarehouse), yet the description is minimal and does not explain the process, consequences, or return values. Without an output schema and with no annotations, more detail is needed for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters described. The description adds no parameter-level detail beyond what the schema already provides, so it meets the baseline for high schema coverage. No additional syntactical or semantic clarification is offered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as validating a draft invoice to make it official, using a specific verb and resource. It distinguishes from other validate_* siblings by specifying 'facture brouillon' (draft invoice). However, the phrase ends ambiguously with 'sans avoir' (without having), which slightly obscures the intended meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 validate_order or validate_proposal. The purpose is implied, but there are no stated conditions, prerequisites, or exclusions. Sibling tools with similar validate_* patterns are present, but the description does not address selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The parenthetical 'makes it official' hints at a state change, but with no annotations, the description fails to disclose other behavioral aspects such as irreversibility, permissions, or downstream actions.
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?
The description is exceptionally brief and front-loaded, with the essential action stated immediately. There is no filler, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a mutation tool with no annotations or output schema, the description is too sparse. It does not explain the consequences of validation, what 'official' means in practice, or any additional requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'id' parameter is not described in the text, and the schema only says it is a number. With 0% schema description coverage, the description should compensate by explaining what ID to provide, but it does not.
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 description clearly states the action ('Valider une expédition') and adds the effect ('la rend officielle'), which distinguishes it from related tools like deliver_shipment. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as deliver_shipment or other validation tools. The description neither states prerequisites nor excludes any scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the action ('validate a draft supplier invoice') without disclosing behavioral traits such as whether the validation is irreversible, what state changes occur, or any side effects. The description adds no transparency beyond the basic intent, leaving the agent uninformed about the operation's impact.
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?
The description is a single, concise sentence with no wasted words. It is front-loaded with the verb and object, making it immediately scannable. This level of brevity is appropriate for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple (one parameter, no output schema, no annotations), the description leaves notable gaps: it fails to clarify the meaning of the 'id' parameter, the expected outcome of validation, or any preconditions. The lack of behavioral transparency and parameter semantics makes the description minimally viable but insufficient for an agent to confidently invoke the tool without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'id' with no description, and the description provides no explanation of what this id refers to. Since schema_description_coverage is 0%, the description should compensate, but it completely ignores the parameter, offering zero added semantics. The only inference is from the tool name, which is insufficient for a clear parameter contract.
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 description 'Valider une facture fournisseur brouillon' clearly states the action (validate) and the resource (draft supplier invoice). It distinguishes this tool from siblings like validate_invoice and validate_supplier_order by specifying 'fournisseur' (supplier) and 'brouillon' (draft), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus other validation tools, such as validate_invoice for regular invoices or validate_supplier_order for supplier orders. There are no prerequisites, exclusions, or alternative tool references, leaving the agent to infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'create' which implies a write operation, but does not disclose side effects, required permissions, whether the intervention is created as a draft or immediately validated, or any other behavioral traits. This is a significant gap 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase, but it is under-specified given the tool's complexity (8 parameters, no annotations, no output schema). The brevity comes at the cost of essential information, making it less useful than an appropriate length would allow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has no output schema, no annotations, and a minimal description. It does not explain return values, side effects, preconditions, or relationships to other intervention-related tools. Given the complexity and lack of structured metadata, the description is inadequate for an agent to correctly invoke the tool without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 75% of parameters (6 out of 8) with clear French labels like 'Durée en secondes' and 'ID du client'. The description itself adds no parameter-specific meaning. With moderate-to-high schema coverage, the baseline of 3 is appropriate.
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 description 'Créer une fiche d'intervention' uses a specific verb (créer) and resource (fiche d'intervention), clearly distinguishing it from sibling tools like get_intervention, list_interventions, and add_intervention_line. This provides unambiguous intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. No exclusions, prerequisites, or contextual hints are given. It simply states the action without any decision framework.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 that it lists countries with their IDs, but does not describe return format, pagination, sorting, authentication needs, or any side effects. For a read operation, this is minimal and leaves significant gaps in understanding what the tool actually returns or how it behaves with parameters.
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?
The description is a single, concise sentence that immediately conveys the core functionality. It is front-loaded and contains no unnecessary words, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and optional parameters, the description should explain return values and parameter usage. It does not mention the structure of the response, how limit/filter work, or any other context needed for correct invocation. The description is too sparse to be considered complete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: only 'filter' has a description, while 'limit' does not. The tool description does not mention any parameters, so it adds no meaning beyond what the schema already provides. It fails to clarify how 'limit' behaves or how 'filter' interacts with the list, which is a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists countries from Dolibarr with their IDs, using a specific verb and resource. It distinguishes itself from sibling tools by focusing on the country resource, which is unique among the siblings, though it does not explicitly contrast itself with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs to retrieve countries, and there is no other country-listing tool among siblings. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives or prerequisites, leaving usage context mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 does indicate this is a read/list operation and provides useful status code context (0, 2, 4, 5, 6, 99). However, it does not disclose behavior such as pagination, returned fields, filtering semantics beyond status, or potential permissions needed.
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?
The description is one concise sentence followed by a compact status legend. It is front-loaded and contains no filler, earning full credit for efficiency and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and only 25% parameter schema coverage, the description is too sparse. It provides status codes but omits response shape, default behavior, filter syntax for sqlfilters, and any mention of pagination or limits. The tool is list-like but still needs more context to be fully usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (user_id is documented). The description adds meaning for the status parameter by listing valid values and their labels, but it leaves limit and sqlfilters completely undocumented. The description only partially compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Lister') and resource ('notes de frais'), so the tool's purpose is unmistakable. It does not differentiate from sibling tools such as list_expenses or get_expense_report, but the resource name is specific enough to avoid major ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like list_expenses, get_expense_report, or the approval workflow tools. It does not mention any prerequisites, exclusions, or preferred use cases beyond the implied action of listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits like parameters affecting results, pagination, or example use cases. However, the description only restates the tool name in sentence form ('Lister les campagnes email/mailing') without adding any behavioral context. It provides no information about return format, ordering, or potential side effects, which is a significant gap for a tool with three parameters.
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?
The description is a single, concise sentence that is easy to read and front-loads the core purpose. It avoids unnecessary filler, which is appropriate for a simple listing operation. However, it is slightly under-specified, leaving out important detail about parameters and usage, but the concise structure itself is not the issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, no annotations, and no output schema, the description is inadequate for an agent to invoke it correctly. It does not mention that filtering is possible via status, that limit controls page size, or that sqlfilters provides advanced query capabilities. The description is complete only in identifying the tool's basic purpose, not in enabling effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is only 33%, with only the 'status' parameter having a description (0=Brouillon, 1=Validé, 2=Envoyé, 3=Annulé). The tool description does not explain the 'limit' or 'sqlfilters' parameters, nor does it give any context for how status filtering works. Since schema coverage is low, the description should compensate but fails to do so, leaving the agent to guess parameter semantics.
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 description clearly states the tool's function: 'Lister les campagnes email/mailing' (List email/mailing campaigns). It uses a specific verb and resource, and it is distinguishable from sibling tools like get_mailing (retrieve a specific mailing), create_mailing, and send_mailing. Even though it is in French, it unambiguously identifies the action and subject.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives such as get_mailing or get_mailing_stats. Its usage is implied by the verb 'list' and the resource 'mailings', but there are no mentioned conditions, exclusions, or comparisons with siblings. It is only minimally instructive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only restates the tool's name in French. It fails to explain the effects of validation (e.g., status change, irreversibility, authorization requirements), offering no meaningful behavioral insight.
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?
The description is a single sentence with no redundancy or unnecessary detail. It is appropriately sized for a simple tool, though the lack of supplementary information is penalized in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is insufficient for complete understanding of the tool's operation. It lacks information about the validation workflow, side effects, or relationship to other validate_* tools, and with no output schema or annotations, the agent cannot infer expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single 'id' parameter with 'ID de la commande fournisseur', and the description adds no additional parameter semantics. Since schema coverage is 100%, the baseline score of 3 applies.
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 description 'Valider une commande fournisseur' clearly identifies the action (validate) and the resource (supplier order). It distinguishes the tool from sibling validation tools like validate_invoice or validate_supplier_invoice by specifying the exact object type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks any mention of prerequisites, state requirements, or exclusions, leaving the agent without contextual cues for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions closing and invoicing, but does not explain side effects, such as whether an invoice is created, if the intervention status changes irreversibly, or what permissions are required.
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?
The description is a single concise phrase, 'Clôturer/facturer une fiche d'intervention', with no fluff or redundancy. It is appropriately sized for a tool with one parameter, though it could be expanded for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutating nature and absence of annotations or output schema, the description is incomplete. It omits crucial behavioral context, such as whether the tool generates an invoice, whether it can be partially applied, and what the expected outcome is for the intervention record.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'id' of type number, with 0% schema description coverage. The description does not mention this parameter or specify that it is the intervention's ID, leaving the agent to infer its meaning solely from the tool name and context.
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 description 'Clôturer/facturer une fiche d'intervention' clearly states the action (close/invoice) and the resource (an intervention record). It distinguishes itself from the sibling validate_intervention by adding the billing aspect, making the tool's specific purpose evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as whether the intervention must be validated first, nor does it exclude cases where this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only indicates a write/configuration action but does not disclose any side effects, reversibility, permission requirements, or impact on existing data. This is minimal transparency.
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?
The description is a single sentence, front-loaded with the purpose, and contains no fluff. It is concise but perhaps too brief to fully compensate for missing behavioral and parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but it is a configuration action with potential side effects. The description does not mention return values, errors, or prerequisites, making it incomplete for an agent to safely invoke without further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter with 0% description coverage. The description explains that 'start_month' represents the month number for the fiscal year start, adding some meaning beyond the parameter name. However, it lacks constraints like allowed range (e.g., 1-12) or examples, so it is only partially helpful.
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 description clearly states the tool configures the fiscal year start month, using a specific verb ('configurer') and resource ('mois de debut de l'exercice fiscal'). It distinguishes itself from sibling configuration tools by targeting this unique fiscal-year setting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites or contextual conditions. The description simply states the action without providing usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the action 'create', which implies a write operation, but does not mention side effects, validation requirements, whether a draft is created, or what the response contains. This is minimal transparency.
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?
The description is a single, clear sentence with no fluff. It is appropriately front-loaded with the verb and object, though it lacks additional helpful context that could make it more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema has 5 parameters (1 required) and no output schema, the description is too sparse. It does not explain contract lifecycle context, relationships to thirdparties, or when to use optional date fields. Sibling tools like list_contracts are not referenced for follow-up actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with complete descriptions for all five parameters (date, socid, date_end, date_start, note_public). The description adds no parameter-specific information, so the baseline score of 3 applies.
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 description 'Créer un nouveau contrat client' uses the specific verb 'Créer' (create) and identifies the resource as 'contrat client' (customer contract). This clearly distinguishes it from the sibling tool 'list_contracts' and other create_* tools for different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., creating a thirdparty first), typical scenarios, or related tools that might be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the prerequisite but omits side effects, whether the entry is posted or draft, validation rules such as balanced lines, or permissions required.
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?
The description is one concise sentence with two meaningful clauses: the core purpose and a necessary prerequisite. Every word earns its place; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite high complexity (accounting entry with a lines array), the description is minimal. There is no output schema, no annotation context, and no explanation of line structure, date format, journal code validation, or error conditions, making it insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and all four parameters are required, yet the description provides no parameter details. It does not explain journal_code values, date format, or the structure of the lines array, leaving the agent without essential guidance.
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 French description clearly states the tool creates a manual accounting entry (OD), specifying the exact verb and resource. This distinguishes it from sibling tools like list_accounting_entries or export_accounting_entries, as no other tool creates journal entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear prerequisite: the chart of accounts must be initialized. However, it does not explicitly state when to use this tool versus alternatives, though the name and description imply it is for manual misc journal entries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must explain behavior fully, but it only says 'generate/regenerate' with no details on side effects (e.g., overwriting existing PDFs), required permissions, or what the output is (file path, binary, success flag). This is a significant gap for a generation tool.
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?
The description is a single, concise sentence in French that communicates the core action efficiently. It contains no fluff and is easily scannable, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (3 simple parameters, no output schema), the description is minimally adequate. It lacks information about return values, error scenarios, or prerequisites, but the modulepart parameter enumerates supported modules. The absence of an output schema shifts some burden to the description, so it falls short of being complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for all three parameters, so the description doesn't need to add much. However, it doesn't enhance the schema descriptions or clarify relationships between parameters (e.g., whether langcode is optional). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: generate/regenerate a PDF for a Dolibarr document. It uses a specific verb and resource, and although it doesn't explicitly distinguish from sibling tools, no sibling tool performs PDF generation, so the purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention contexts like regenerating an existing PDF versus creating a new one, nor does it reference related tools such as get_document or delete_document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not explicitly state that the operation is read-only, what data freshness applies, or the scope of the data returned, though 'dashboard' weakly implies a read-only summary.
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?
The description is concise and front-loaded, using a single phrase to convey the dashboard's main contents. It is appropriately sized for a simple tool, though it could add a few more clarifying details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description's outline of the dashboard contents is helpful but not fully complete. It does not explain the relationship to sibling summary tools or detail the exact fields or sections included, leaving some ambiguity about the return structure.
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?
The tool has no parameters, so no parameter semantics are needed. The description adds contextual value by listing the content areas, which is appropriate for a parameter-less tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a complete dashboard covering accounting configuration, bank balances, and VAT, giving it a clear scope that distinguishes it from other specific getters like get_vat_report or get_bank_transactions. However, it lacks an explicit verb such as 'retrieves' or 'displays', relying on the noun 'dashboard' to imply the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_financial_summary or get_accounting_config. There are no mentions of scenarios, exclusions, or preference for this aggregated view.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'get details' without disclosing whether it is read-only, what happens if the leave request is not found, authentication requirements, or any side effects. The behavior is largely opaque.
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?
The description is a single, concise sentence that states the core purpose without extraneous words. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple parameter set and no output schema, but the description lacks behavioral transparency and usage guidance. For a getter tool with no annotations, the description is minimal and does not adequately inform the agent about expected behavior or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'id' of type number, and the description does not explain its meaning. With 0% schema description coverage, the description should compensate but does not. The parameter's semantics are only inferable from the tool name, not explicitly stated.
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 description 'Obtenir les détails d'une demande de congé' clearly states a specific action (get details) on a specific resource (leave request). This distinguishes it from sibling tools like list_leave_requests (list all), create_leave_request, approve_leave_request, and refuse_leave_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, nor any prerequisites or context. While the purpose implicitly suggests using it to retrieve details, there is no explicit mention of needing an id or when it should be preferred over listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as return format, error handling, or the fact that it performs a read-only operation. It only says 'get details' without further context.
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?
The description is a single, concise sentence that directly states the tool's purpose. It contains no unnecessary words and is front-loaded with the verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, this description is incomplete. It omits information about the expected return payload, error scenarios, and when to use this tool over list_members.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no property descriptions (0% coverage), and the description does not explain the 'id' parameter's format or purpose. The agent must infer from the tool name that 'id' refers to the member ID.
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 description clearly states the action ('obtenir' = get) and the resource ('détails d'un membre'), distinguishing it from sibling tools like list_members or create_member. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention that it is for fetching a single member by ID, nor does it contrast with list_members.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of explaining behavior beyond the basic listing. It does not disclose what the response contains, whether it returns all object types or just the one specified, or any potential limitations (e.g., pagination, authentication). The description is minimal and lacks behavioral detail.
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?
The description is a single, concise sentence in French that conveys the essential purpose without unnecessary words. It is perfectly sized for a simple listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 simple parameters) and no annotations or output schema, the description provides a basic understanding but lacks details about the return format or edge cases. It is minimally viable but leaves room for ambiguity about what objects are listed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (id and type) with clear descriptions, covering 100% of the parameter semantics. The description itself adds no parameter information, but it is not needed since the schema is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('list') and the resource ('objects belonging to a category'), which is specific enough to understand the tool's core function. It distinguishes from siblings like add_object_to_category and list_categories, though it doesn't explicitly mention alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus other listing tools like list_products or list_customers. The description only states what it does, not the context or scenarios where it is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the basic action, such as read-only nature, permission requirements, error handling, or return format.
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?
The description is a single, clear sentence with no extraneous information, perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and guidance on usage or parameters, the description is minimal and leaves out important context for correct invocation, especially for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the 'id' parameter, and the description does not compensate by explaining that 'id' is the identifier of the reception, leaving the parameter semantics unsupported.
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 description clearly states the action (get details) and the resource (supplier reception), effectively distinguishing it from sibling list_receptions by specifying 'details' and 'fournisseur'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving details, but does not explicitly state when to use it versus list_receptions or other related tools, nor does it mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'list' without mentioning read-only nature, pagination, return format, or any side effects. This is insufficient for an operation with 5 parameters and no output schema.
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?
The description is a single, well-structured sentence. It is front-loaded with the core action and resource, and the parenthetical clarifies the event types without waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too thin. It identifies the resource but omits any details about return values, filtering behavior, pagination, or limitations. For a tool with 5 parameters, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics. Schema coverage is 60%, with 'limit' and 'sqlfilters' lacking descriptions, and the description does not compensate. The agent gets no additional context beyond what the schema already provides.
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 description uses the specific verb 'Lister' (List) with the resource 'événements de l'agenda CRM' and enumerates the event types (calls, meetings, emails, tasks). This clearly distinguishes it from sibling tools like create_agenda_event and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It simply states what it does, implying usage but never explicitly stating context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavior, but it only restates the function. It fails to mention filtering by status or product, pagination limit, or any side effects/return format.
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?
Single sentence, front-loaded, no waste. The parenthetical definition of BOM adds clarity without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description is too sparse for a 4-parameter list tool. It omits filter semantics, pagination, and return expectations, making it minimally usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter meaning beyond the schema. Schema covers status and product_id, but limit and sqlfilters are unexplained; description does not compensate for the 50% coverage gap.
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?
Description uses specific verb 'Lister' and resource 'nomenclatures (BOM)', clearly identifying it as a list operation. It distinguishes from sibling tools get_bom and create_bom by indicating plural/listing scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_bom (single BOM) or create_bom. There is no mention of appropriate contexts 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only states the purpose and the type mapping. It fails to mention output format, pagination, or any side effects, leaving the agent without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, but the second sentence redundantly repeats the type mapping already present in the schema. It is not overly long, but it does not fully earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description lacks essential information about return values, pagination, and the use of limit/sqlfilters. The absence of an output schema and these details makes the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only 'type' has a schema description). The description repeats the type mapping but does not explain 'limit' or 'sqlfilters' at all, so the description fails to compensate for the missing schema descriptions.
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 description uses a specific verb 'Lister' (list) and a clear resource 'catégories Dolibarr', making the action unmistakable. The type mapping adds further specificity, distinguishing it from category creation or object-category tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose itself implies when to use the tool (when a list of categories is needed), but there is no explicit guidance on when not to use it or how it compares to sibling tools like get_objects_in_category or create_category. This is minimal implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning read-only nature, pagination, potential side effects, or required permissions. For a list operation, this lack of detail is a notable gap.
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?
The description is a single, front-loaded sentence with zero wasted words. It is highly concise and appropriately sized for a simple list operation, matching the standard of efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description should provide more context about return values, pagination, or usage constraints. It fails to do so, leaving the tool under-specified for an agent to invoke confidently. A list operation with filters deserves at least some behavioral or contextual detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes 'status' and 'thirdparty_id' but leaves 'limit' undocumented (67% coverage). The tool description adds no parameter context, failing to clarify what 'limit' controls or how filters relate to the listing. The description does not compensate for the missing schema detail.
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 description uses the specific verb 'Lister' (to list) and clearly identifies the resource as 'contrats/abonnements clients' (client contracts/subscriptions). This distinguishes it from sibling tools like list_projects or list_orders, making the purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any filters, prerequisites, or exclusions. It simply restates the action, leaving the agent without context on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source of behavioral info. It discloses status values but does not mention read-only nature, pagination behavior, filter usage, or return format. It leaves the agent to infer basic behavior from the name.
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?
The description is extremely concise, with the core action and status mapping in a single line. It front-loads the key information without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 5 parameters and no output schema, the description omits essential context such as pagination defaults, filter syntax, and what response to expect. It does not differentiate from list_invoices (customer invoices), which is a nearby sibling, except by the word 'fournisseurs'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20% (status has a description). The description clarifies status 1 as 'Validée/Impayée', adding meaning to that parameter, but it offers no explanation for page, limit, sqlfilters, or thirdparty_ids. It fails to compensate for the low schema coverage.
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 description uses the specific verb 'Lister' with the resource 'factures fournisseurs' (supplier invoices), clearly distinguishing it from the sibling tool 'list_invoices' which likely handles customer invoices. The status mapping provides additional scoping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over alternatives like list_invoices or list_supplier_orders. Sibling tools are not referenced, and no exclusions or specific use cases are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the core function and does not reveal important behaviors such as the optional nature of the project filter, pagination/limit behavior, or what the result structure looks like.
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?
The description is a single, concise sentence with no unnecessary words. It is front-loaded with the verb and resource, making the purpose immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or an output schema, the description is too sparse to give an agent full context. It omits the optional project filter (present in the schema but not in the description) and lacks any mention of result format or parameter semantics. For a simple list tool, it remains insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents project_id but not limit, giving 50% coverage. The description adds no parameter details beyond the schema's own description; it does not explain limit or how omitting project_id affects the result. The description fails to compensate for the undocumented parameter.
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 description 'Lister les tâches d'un projet' clearly states the action (list), the resource (tasks), and the scope (project). It is specific and distinguishes from sibling tools like list_projects or get_project, which handle different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that project_id is optional or that limit controls the number of results, nor does it reference any other tool for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention whether this is a read-only operation, pagination behavior, return format, permissions, or any side effects. The phrase 'Lister' implies a read-only list, but no details are given.
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?
The description is a single concise sentence that front-loads the core function. There is zero redundant information, and it is appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is the only source of guidance. It fails to provide usage guidelines, parameter semantics, or behavioral details, making it incomplete for an agent to reliably invoke the tool in varied contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 50% description coverage (only 'active' is explained). The description does not add any parameter context, leaving 'limit' undocumented and not explaining how the parameters interact or their defaults beyond what the schema already states.
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 description uses a specific verb ('Lister') with a clear resource ('utilisateurs Dolibarr') and adds scope clarification ('employés, commerciaux, admins'). It clearly distinguishes from sibling tools like list_members or list_contacts, which target different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or alternative tools (e.g., list_members, list_contacts). The usage context is only implied by the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action without revealing side effects, idempotency, validation, permissions, or error behavior. This is insufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the core purpose without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple setter, the description lacks contextual information such as return behavior, error conditions, or how it interacts with other pricing tools. No annotations or output schema exist, so the description should do more to support correct invocation, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: only price_level is described, while thirdparty_id is not. The tool description adds minimal clarity by indicating the thirdparty is a customer, but it does not compensate for the undocumented parameter or provide additional syntax/constraints beyond the 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 description 'Définir le niveau tarifaire d'un client' clearly states the action (set) and the resource (a customer's price level). It is specific enough to be distinguished from sibling tools like get_thirdparty_price_level and set_thirdparty_discount.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention related tools such as get_thirdparty_price_level or any prerequisites like requiring the thirdparty to exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
En l'absence d'annotations, la description doit porter le fardeau de la transparence. Elle indique l'action de création (mutation) mais ne précise pas les effets secondaires, l'idempotence, les permissions requises, ni le comportement en cas de cotisation existante. Ce manque d'informations est problématique pour un outil de mutation.
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?
La description est une phrase unique, directe, sans mot inutile, et bien structurée. Elle est front-loadée et efficace. Cependant, elle est très courte, ce qui peut être vu comme une sous-spécification plutôt que de la concision optimale.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Avec 6 paramètres, aucune annotation et aucun schéma de sortie, la description ne fournit pas suffisamment de contexte. Une phrase unique ne couvre ni les prérequis, ni le comportement attendu, ni les conditions d'utilisation. L'agent ne peut pas correctement anticiper les conséquences de l'appel.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Le schéma couvre 100% des paramètres avec des descriptions individuelles, donc la note de base est 3. La description n'ajoute aucune information supplémentaire sur les paramètres, leurs relations, ou les contraintes de format (ex. dateend après date). Le texte reste en dessous du niveau fourni par le schéma.
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?
La description utilise un verbe spécifique « Créer » et une ressource claire « cotisation/abonnement pour un membre », ce qui indique précisément l'action et la cible. Elle se distingue des outils frères comme create_member (créer un membre) ou list_member_types. La finalité est immédiatement compréhensible.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Aucune indication sur quand utiliser cet outil par rapport aux alternatives. La description ne mentionne pas de prérequis (ex. le membre doit exister) ni de cas d'exclusion. Aucune référence à un outil alternatif n'est fournie.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it does not. It fails to mention side effects (e.g., whether the category is modified), error conditions (e.g., duplicate object), or permission requirements. The one-line description gives no behavioral context beyond the action itself.
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?
The description is a single, front-loaded sentence that conveys the essential information without any wasted words. It is appropriately concise for a simple action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should compensate by explaining return values, failure behavior, or context. It does none of this. The description only names the action, leaving the agent without enough context for a reliable invocation, especially regarding outcome expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description, so the baseline is 3. The description adds no additional meaning beyond the schema; it does not elaborate on the relationship between parameters or usage nuances. Thus, it meets but does not exceed the baseline.
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 description 'Ajouter un objet à une catégorie' clearly states a specific action (add) and resource (object to category), and is distinct from sibling tools like get_objects_in_category or create_category. Its brevity still conveys the core operation effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or related tools, leaving the agent to infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only reveals the 'draft' nature ('brouillon') but omits side effects, required permissions, the need for a third-party ID, or follow-up workflow. For a state-changing tool, this is insufficient.
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?
The description is a single, front-loaded sentence with no filler or redundant information. Every word contributes to understanding the tool's core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and no annotations, the description is too sparse. It does not clarify that the invoice is only a draft header, that lines must be added separately, or what the response will contain, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3 applies. The description adds no extra parameter meaning beyond what the input schema already provides.
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 description uses a specific verb ('Créer') and resource ('facture brouillon pour un tiers'), clearly indicating the tool creates draft invoices for third parties. This distinguishes it from sibling tools like create_credit_note and create_supplier_invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention that this only creates a draft invoice header and that subsequent steps (adding lines, validation) require separate tools like add_invoice_line and validate_invoice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits on its own. It only says 'create', implying a write operation, but does not mention return values, initial status (e.g., draft), permissions, or side effects. This is minimal 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's purpose. Every word is useful, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, create operation) and the absence of an output schema or annotations, the description is incomplete. It does not explain what the tool returns (e.g., new proposal ID), whether the proposal is created in draft status, or the need to add lines via add_proposal_line afterward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 7 parameters (100% coverage), so the description does not need to add parameter details. The description itself adds no extra parameter context, but the schema is sufficient, warranting a baseline score of 3.
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 description clearly states 'Créer un nouveau devis commercial pour un tiers' (Create a new commercial quote for a third party), providing a specific verb, resource, and recipient. This distinguishes it well from siblings like list_proposals, get_proposal, and add_proposal_line.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description simply states the action without mentioning prerequisites, related workflow steps (e.g., adding proposal lines), or why one would choose this over similar creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose a significant behavior: calculation from invoices when the chart of accounts is uninitialized. However, it omits other relevant details such as requiring date parameters, handling of limits, or the structure of the exported CSV.
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?
The description is extremely concise: a single sentence with two clauses. There is no wasted wording. It loses a point because it is terse to the point of underspecification, but as a concise statement, it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and three parameters. The description only provides a hint about an edge case (uninitialized chart of accounts) but lacks essential context such as the meaning of the date range, the limit parameter, and what the CSV contains. It is incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention any parameter. The three parameters (date_start, date_end, limit) are completely unexplained, forcing the agent to guess their meaning and required format.
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 description clearly states the action: 'Exporter les écritures comptables en CSV' (export accounting entries to CSV), specifying both the resource and the output format. This distinguishes it from sibling tools like list_accounting_entries, which lists entries but does not mention CSV export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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. The mention of 'Calcul depuis les factures si plan comptable non initialisé' provides a condition (calculation from invoices when chart of accounts not initialized) but does not clarify when to choose this over list_accounting_entries or other accounting tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it is a 'report' (implying read-only), but does not describe required parameters (account_id is required but unmentioned), date range behavior, or what the response contains beyond the matched/unmatched distinction. This lack of detail is a significant gap for a report tool.
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?
The description is a single concise sentence in French, with no redundant information. It is front-loaded and efficient, but the extreme brevity sacrifices necessary details, making it slightly under-specified for a tool lacking annotations and schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 0% schema description coverage, the description must provide all context. It only covers the core purpose (matched vs unmatched lines) but omits parameter semantics, date handling, and return structure. This is insufficient for an agent to invoke the tool correctly with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has three parameters (account_id, date_start, date_end) with no descriptions (0% coverage). The description does not explain the meaning or format of these parameters. While account_id is somewhat inferable from the tool name, the date parameters and their optionality are not clarified, leaving the agent to guess.
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 description 'Rapport de rapprochement bancaire (lignes rapprochées vs non-rapprochées)' clearly identifies the tool as returning a bank reconciliation report with matched and unmatched lines. It distinguishes from siblings like get_bank_transactions (list transactions) and reconcile_bank_line (action), making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to view bank reconciliation status by mentioning matched/unmatched lines, but it provides no explicit when-to-use guidance or alternatives. It does not state when this should be preferred over get_bank_transactions or reconcile_bank_line, making usage guidance only indirectly inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Lister' implies a read-only operation, but the description does not explicitly state that it has no side effects, nor does it mention pagination, ordering, default limits, or error behavior. The 'filtres de date' mention duplicates the sqlfilters parameter description, adding no unique behavioral context.
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?
The description is a single, concise sentence that front-loads the core action and resource. It is appropriately sized with zero wasted words, and the key modifier (date filters) is placed upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 what is returned (e.g., a list of transaction objects) but does not. It also omits usage context such as the required account_id or behavior when no transactions are found. Given the low complexity, a brief note on return structure or impact of the limit parameter would have made it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for limit, account_id, and sqlfilters. The tool description adds no additional parameter semantics beyond indicating the presence of date filters, which is already captured in the sqlfilters parameter description. Baseline 3 is appropriate since the schema does the heavy lifting.
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 description uses a specific verb 'Lister' (list) with a clear resource 'transactions d'un compte bancaire' (transactions of a bank account), and mentions a key feature (date filters). It distinguishes from siblings like add_bank_transaction and get_bank_reconciliation by focusing on listing, making it clear when this tool is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_bank_reconciliation or list_bank_accounts. It only states what it does, without exclusions, prerequisites, or mention of other related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 that components and quantities are retrieved, but does not state whether the operation is read-only, error behaviors, permissions, or return format. This is insufficient for a tool with zero annotation coverage.
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?
The description is a single, front-loaded sentence with no extraneous words. It clearly communicates the core purpose in a concise manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description gives the essential purpose but omits details about the return structure, how the id is used, and error cases. It is minimally adequate but not fully complete for an agent to invoke with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single required id parameter with 0% description coverage. The description does not mention the id or explain its role, leaving the agent to infer that it identifies the BOM. The description fails to compensate for the lack of schema descriptions.
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 description clearly states the tool retrieves BOM details, listing components and quantities. It uses a specific verb+resource and distinguishes from siblings like list_boms (list) and create_bom (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is the sole source of behavioral disclosure. It indicates a read operation ('Lire') but does not mention return format, response size, pagination, or any potential side effects, which is insufficient for an agent.
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?
The description is a single, efficient sentence that immediately conveys the tool's purpose. It is front-loaded with the key verb and resource, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about the return structure, which is critical because there is no output schema. It does not explain what the 'constants' look like (e.g., key-value format), how many are returned, or how module filtering affects the result, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the 'module' parameter with examples. The description adds no further meaning beyond the schema, so the baseline of 3 applies given 100% schema coverage.
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 description clearly states the tool reads global configuration constants of Dolibarr, using the specific verb 'Lire' (read) and identifying the resource. It naturally distinguishes from the sibling 'set_setup_value' and other config getters like 'get_accounting_config' by focusing on global settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions or conditions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'list' without mentioning what the response looks like, whether both id and ref can be provided, or if any permissions are needed. Minimal context is given beyond the basic action.
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?
The description is a single, concise sentence that is front-loaded with the key purpose. There is no wasted wording, and it is appropriately sized for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should clarify what to expect. It fails to mention that either id or ref must be provided to identify the object, nor does it describe the return value or behavior when no parameters are given. This leaves significant gaps for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 context that documents are attached to an object, implying id/ref identify that object, but does not explain the distinction between id and ref or the meaning of modulepart beyond what the schema provides. Baseline 3 is appropriate.
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 description clearly states the tool lists documents/files attached to a Dolibarr object, using a specific verb and resource. It distinguishes from sibling tools like get_document, delete_document, and generate_document_pdf by focusing on listing attached documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as get_document for retrieving a single document or generate_document_pdf for creating PDFs. It does not mention prerequisites like needing modulepart or that id/ref identify the parent object.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the listing action and repeats the status codes already present in the schema. It does not disclose pagination behavior, default limits, return format, or explicitly indicate that it is a read-only operation.
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?
The description is concise and front-loaded with the primary purpose. However, the status mapping is redundant with the schema, slightly diminishing efficiency. Still, the overall length is appropriate with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list with a complete schema, the description is functional but lacks context on pagination usage, sqlfilters capabilities, and expected output shape. It is minimal but not misleading.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all four parameters described. The tool description adds no new parameter information—it merely repeats the status mapping already provided in the schema. Baseline of 3 applies because the schema documents the parameters adequately.
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 description clearly states the specific verb 'Lister' (list) and the resource 'devis/propositions commerciales' (quotes/commercial proposals), distinguishing it from singular get_proposal and other list_* tools. The status code mapping adds specificity and clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool instead of alternatives like get_proposal or other list_* tools. There is no mention of exclusions, prerequisites, or contexts where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only mentions 'gestion des niveaux tarifaires' but does not explain effects on existing prices, idempotency, permissions, or return values.
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?
The description is a single concise sentence that front-loads the core action and purpose. No wasted words, and it includes a relevant qualifier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 6 parameters, no output schema, and no annotations, the description is extremely brief. It lacks information about return values, side effects, or behavior variants across price levels, which is insufficient for safe and effective usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter descriptions in the schema already document all 6 parameters. The tool description adds minimal value beyond mentioning price level management, which is already captured in the price_level parameter description.
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 description clearly states the tool's function: setting or modifying a product's price. It also mentions price-level management, which adds specificity and helps distinguish it from generic product update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like update_product or get_product_prices. No context about prerequisites, typical use cases, or exclusion criteria is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The warning about caution is generic and does not explain potential side effects, required permissions, persistence behavior, or whether changes take immediate effect. For a tool that modifies global configuration, this is insufficient.
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?
The description is a single, direct sentence followed by a concise warning. It is appropriately sized, with no unnecessary wording or repetition, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a generic setter for global configuration constants, which can have widespread effects. However, the description lacks essential context such as when to use it, what cautions to observe, and what the broader impact is. Even with a complete schema, the missing usage and behavioral context makes it incomplete for an agent to safely invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters with clear descriptions (e.g., constant name examples), so baseline is 3. The description adds no additional parameter semantics beyond the schema, but it also doesn't need to since coverage is complete.
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 description clearly states the action: 'Modifier une constante de configuration globale de Dolibarr' (modify a global configuration constant). This distinguishes it from sibling tools that handle specific configuration areas (e.g., configure_vat_mode, configure_fiscal_year) by indicating it is the generic setter for any configuration constant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus the many sibling configuration tools. It lacks any mention of exclusions, prerequisites, or scenarios where this generic setter is preferred over dedicated configuration tools. The warning 'Utiliser avec précaution' hints at caution but does not provide actionable usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral transparency. It reveals the discount is permanent but does not explain whether it overwrites existing discounts, if it affects historical documents, or if special permissions are required. The '0 to remove' detail is in the schema, not the description, leaving side effects largely undisclosed.
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?
The description is a single, concise sentence that immediately states the tool's purpose. It is well-structured and avoids redundancy, with every word contributing to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the essential purpose but lacks context about when to use it relative to related discount tools and what the expected result (e.g., return value) is. Given the absence of an output schema and the existence of closely related siblings, a slightly richer description would improve completeness, but the core is minimally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the tool description adds no parameter-level information. It does clarify that thirdparty_id refers to a customer, but that is implicit from 'client'. The description doesn't compensate for the missing explanation of thirdparty_id, and discount_percent semantics are already fully covered in the 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 description 'Définir la remise commerciale permanente d'un client (en %)' clearly states the action (set), the object (permanent commercial discount), and the scope (a customer). It distinguishes itself from sibling tools like get_thirdparty_discount (retrieval) and set_thirdparty_price_level (price level), making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are prerequisites or edge cases (e.g., what happens if the third party doesn't exist) addressed. The description solely defines the operation without any contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'Add an expense line' without mentioning side effects (e.g., does it update totals?), prerequisites (parent expense report must exist), or error behavior. This is insufficient for a write operation.
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?
The description is a single, concise sentence that is front-loaded with the verb and resource. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is straightforward, and the schema thoroughly documents parameters, but the description lacks usage guidance and behavioral context (e.g., no output schema, no prerequisites, no return value details). It is minimally viable but not enriched.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is high (88%), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides, but it does not need to compensate.
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 description clearly states the action (ajouter = add) and the resource (ligne de dépense à une note de frais = expense line to an expense report). It distinguishes from sibling tools like add_invoice_line or add_proposal_line by specifying the expense report context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor any prerequisites (e.g., an existing expense report must be created first). The description only states the action without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only repeats the tool's action ('create a new contact') and adds no context about permissions, side effects, or return values. It does not mention that this is a mutation or what happens after creation.
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?
The description is a single, concise sentence with no filler. It is front-loaded and immediately conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple create operation with a well-documented schema, but the description lacks guidance on when to use it, what it returns (no output schema), and any prerequisites like linking to a third party. These gaps make it minimally adequate but incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptive parameter names and explanations (e.g., socid is 'ID du tiers…'). The description itself adds no parameter semantics, so the baseline score of 3 is appropriate because the schema does the work.
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 description 'Créer un nouveau contact individuel' clearly states the verb (create) and resource (individual contact), distinguishing it from sibling tools like create_thirdparty (which creates a company). It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool over alternatives—for example, it doesn't clarify that this is for individual persons vs. companies (create_thirdparty). No exclusions or alternative tool mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the creation action without mentioning potential side effects, such as uniqueness constraints on 'ref', auto-calculation of fields like 'price_ttc', or any required permissions. This lacks the context needed for safe invocation.
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?
The description is a single concise sentence in French, front-loading the verb and direct object with no superfluous words. It is efficiently structured and immediately comprehensible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 15 parameters and no output schema, the description is minimal but not wholly inadequate. The schema fully documents parameters, and the creation action is straightforward. However, it does not mention return values, required permissions, or any validation behavior, leaving the agent without some important context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds no parameter-specific information beyond what the schema already provides, though it does hint at the 'type' parameter by mentioning both products and services. It neither enhances nor detracts from the schema's clarity.
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 description clearly states the action with a specific verb 'Créer' (create) and names the resource 'produit ou service' (product or service) as well as the location 'catalogue' (catalog). This unambiguously distinguishes the tool from siblings like update_product and get_product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or references to related tools such as update_product or get_product. The use case is only implied by the verb 'create'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool deletes a document, but does not disclose whether deletion is permanent, whether it checks for references, what happens to linked records, or if there are any permissions or side effects. This is a significant gap for a destructive operation.
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?
The description is a single, short sentence that is front-loaded with the essential verb and resource. It avoids fluff and every word contributes to meaning, making it highly concise and easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it is a destructive delete operation with no annotations and no output schema, the description is incomplete. It fails to explain what 'attached' means, how the parameters relate to each other, whether the document is permanently deleted, or any safety considerations. The moderate schema coverage does not resolve these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: 'original_file' has a description ('Chemin complet du fichier'), but 'modulepart' is undocumented. The tool description adds no information about parameter meaning or usage, failing to compensate for the missing 'modulepart' semantics.
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 description 'Supprimer un document attaché' clearly states the action (delete) and the resource (an attached document). This distinguishes it from sibling tools like list_documents, get_document, and generate_document_pdf, which are non-destructive operations on documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you need to delete an attached document. However, it does not explicitly state when not to use it, mention alternatives, or provide context about prerequisites (e.g., whether the document must be detached first or if deletion is permanent).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions the content (invoices, payments, balance) but does not disclose behavioral details like date range filtering, whether the balance is current or date-specific, or the return structure. The read-only nature is only implied by the tool name.
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?
The description is a single concise sentence that front-loads the main purpose. It is efficient and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and schema descriptions, plus three parameters, the one-line description is insufficient. It does not explain the date range concept, the meaning of the balance, or how this tool fits among the many related financial tools, making it hard for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the three parameters (thirdparty_id, date_start, date_end). It only implies thirdparty_id via 'd'un client' but provides no meaning for the date fields or their optionality, leaving the agent to infer their purpose.
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 description clearly states the tool returns a complete customer statement (invoices, payments, balance) with a specific verb and resource. It distinguishes from siblings like get_thirdparty_invoices or get_aged_balance by emphasizing the comprehensive nature of the statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a full customer statement but provides no explicit guidance on when to use this tool versus alternatives such as get_thirdparty_invoices or get_financial_summary. No exclusions or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of disclosing behavior. It lists what the summary includes but does not explicitly state that the operation is read-only, has no side effects, or requires any specific permissions. The content description is helpful, but behavioral traits beyond the obvious 'get' are not disclosed.
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?
The description is a single, well-structured sentence that immediately states the purpose and specifies the key content areas. There is no redundancy or filler; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one optional parameter and no output schema, so the description must convey what the summary returns. It lists the main components but does not specify the return structure, currency, or any additional details that could help the agent interpret the result. This is adequate but leaves gaps in expectation setting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameter semantics, describing the 'year' parameter as the fiscal year with a default to the current year if empty. The tool description adds no additional parameter information, so the baseline of 3 is appropriate.
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 description clearly states the tool's function: obtaining a financial summary with specific components (total revenue, unpaid invoices, cash balance, and key indicators). The verb 'Obtenir' plus the resource 'résumé financier' makes the purpose unambiguous and distinct from more specialized financial reports like get_vat_report or get_trial_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other financial reporting tools, nor are any exclusions mentioned. The description simply states what it does without contextualizing it against siblings such as get_aged_balance or get_customer_statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden for behavioral disclosure. It doesn't explicitly state whether this is a read-only operation, any authentication requirements, or behavior when the product doesn't exist. The verb 'get' implies safety but this is not clearly disclosed.
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?
The description is a single concise sentence that is front-loaded with the action and resource. Every word contributes meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and no output schema, the description explains what the tool does but doesn't describe the structure or format of the returned price levels. While adequate for a simple getter, it could mention that the response contains multiple levels with associated pricing details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes product_id as 'ID du produit' with 100% coverage. The description adds minimal context by mentioning 'd'un produit' but doesn't explain the parameter further. No additional constraints or relationships are added, making this baseline acceptable.
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 description clearly states the tool retrieves price levels for a product, specifying 'tous les niveaux tarifaires' (all price levels). This specific verb+resource+scope distinguishes it from sibling tools like get_product and set_product_price.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_product or get_thirdparty_price_level. There are no exclusions, prerequisites, or context about when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 clearly indicates a read operation ('consulter'), but it does not explain what stock means (e.g., available vs. physical), pagination behavior, or whether zero-stock items are included. This lack of detail may lead to incorrect assumptions.
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?
The description is a single, concise sentence that front-loads the action and resource. Every word adds value, with no redundancy or filler. It is appropriately sized and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description should provide more context about return values and parameter behavior. It does not mention pagination (despite the 'limit' parameter), response format, or inclusion criteria. The tool has limited complexity, but the description leaves critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 adds meaning for 'id' (it's the warehouse, implied by 'dans un entrepôt') but does not explain the 'limit' parameter at all. The description partially compensates for the schema but is insufficient for full parameter understanding.
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 description 'Consulter le stock de tous les produits dans un entrepôt' explicitly states the action (view stock) and the resource (all products in a warehouse), making it distinct from siblings like get_product_stock which targets a single product. The scope is clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool's usage context (when you need stock for all products in a specific warehouse), but it does not explicitly mention alternatives or exclusions, such as using get_product_stock for a single product. The usage is implied but not contrasted with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose default filtering behavior, pagination, or whether it returns active/inactive types, offering minimal behavioral insight.
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?
The description is a single, succinct sentence that immediately conveys the verb and object with no filler or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description covers the core function but omits return format and default behavior. It is adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the only parameter 'active' with 100% coverage ('1=Actifs seulement'). The description adds no further meaning or context about the parameter.
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 description states a specific verb 'Lister' and resource 'types de congés' (leave types), clearly distinguishing it from sibling tools like list_leave_requests which list requests not types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, no exclusions, and no alternatives. It simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'Lister' implies a read-only operation, which is clear. However, no additional behavior is disclosed (e.g., pagination defaults, whether it returns both products and services based on the mode parameter). For a simple list operation, this is adequate but not rich.
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?
The description is a single concise sentence, front-loaded with the action and resource. It contains no fluff or repetition, making it maximally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and no annotations. The description explains the core purpose but does not mention return format, pagination behavior, or filter options beyond what the schema already conveys. For a straightforward list tool, this is adequate but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 80% of parameters with descriptions (mode, limit, in_stock, sqlfilters) and only 'page' lacks a description. The description itself adds no parameter information beyond the schema, so it relies on the schema, which is mostly sufficient. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists products and services from the Dolibarr catalog, using a specific verb and resource. It does not explicitly differentiate from sibling tools like get_product, but the plural 'list' vs singular 'get' makes the distinction implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description only states what it does, not when to choose it over similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only states the operation and status values. It doesn't mention that listing is read-only, pagination behavior, default limits, or authentication requirements. This is a significant gap for a tool with zero annotation support.
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?
The description is exactly two sentences, with the primary purpose in the first sentence and the status legend in the second. There is zero fluff or repetition, making it extremely concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 should provide more context. It covers the status parameter adequately but omits details on pagination, filtering, return format, and operational behavior. It's minimally adequate but leaves clear gaps for a smooth invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds crucial meaning for the 'status' parameter by mapping numeric codes to statuses, which the schema completely lacks. However, it does nothing to explain 'page', 'limit', 'sqlfilters', or 'thirdparty_id'. With schema description coverage at 0%, this is only a partial compensation, leaving several parameters underspecified.
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 description clearly states the action ('Lister') and the resource ('les expéditions/bons de livraison'), making it unambiguous. It also provides a status code legend, which adds specific scope and distinguishes the list operation from singular get_shipment or creating tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives like get_shipment for a single shipment. It doesn't mention prerequisites, filtering use cases beyond status, or any exclusions. The status codes hint at filtering but don't qualify as usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It only mentions adding an operation and cash inflow/outflow. It does not describe whether this creates a durable ledger entry, requires an existing account, affects reconciliation, or what the return value is—significant gaps for a mutating tool.
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?
One short, front-loaded sentence conveys the core purpose without filler. Every word contributes value, and no redundant structure exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a write operation with no output schema and no annotations. The description does not explain return behavior, prerequisites, or downstream effects. While the schema covers parameters, the overall usage context remains incomplete for an AI agent deciding whether and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all six parameters including amount sign and type codes. The description adds no extra parameter context, so the baseline of 3 is appropriate.
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 description clearly states a specific verb ('Ajouter') and resource ('opération bancaire manuelle'), and adds the scope of 'entrée ou sortie de trésorerie'. It distinguishes itself from read-only siblings like get_bank_transactions and reconciliation tools by emphasizing the manual add action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The term 'manuelle' implies usage for manual bank entries rather than automated/reconciled ones, but no explicit alternatives or exclusions are provided. The description gives context but does not guide when to choose this over tools like add_payment_to_invoice or reconcile_bank_line.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It indicates the action (add a line) and the two input styles, but it does not state potential side effects (e.g., invoice total recalculation), whether the line can be added to any invoice status, or what the response looks like. For a mutation tool, this is insufficient.
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?
The description is two short French sentences, front-loaded with the action and resource. It contains no filler and conveys the core purpose and mode distinction efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and no annotations, the description is too sparse. It omits a critical usage nuance: although desc and fk_product are schema-optional, the tool likely requires at least one of them to create a meaningful line. It also does not mention product_type implications, invoice status restrictions, or the outcome of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds modest value by reinforcing that fk_product and desc are alternative ways to define the line, but it largely repeats what the parameter descriptions already say (e.g., desc is 'service libre ou nom du produit'). It does not clarify the implicit need to provide one of these despite both being optional in the 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 description uses a specific verb ('Ajouter une ligne') and clearly identifies the resource (une facture), which distinguishes it from sibling line-adding tools for orders, proposals, and supplier invoices. It also clarifies the two main modes (catalog product via 'fk_product' vs free line via 'desc').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this is for invoices and offers mode-selection guidance (fk_product vs desc), but it does not explicitly mention when not to use this tool compared to alternatives like add_order_line or add_supplier_invoice_line, nor any preconditions (e.g., invoice must be draft).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only states the action without disclosing side effects, required order status, or consequences. It does not mention whether the line can be added only to draft orders or if totals are recalculated.
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?
The description is a single concise sentence with no redundant words, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, output schema, or conditions, the sparse description leaves out important operational context such as preconditions, return value, or error behavior. While the schema covers parameters, the description fails to explain the operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters have schema descriptions covering 100% of semantics, so the description adds no additional parameter information. The baseline 3 applies.
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 description uses a specific verb 'Ajouter' and resource 'ligne' targeting 'commande client', clearly distinguishing from sibling add_*_line tools for proposals, invoices, or supplier orders. The scope is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding lines to customer orders, but does not explicitly state when to prefer it over alternatives like add_proposal_line or add_supplier_order_line. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the prerequisite that the invoice must be 'validated' but does not disclose side effects such as updating invoice status, closing the invoice if fully paid, or any accounting implications. The closepaidinvoices parameter hints at behavior, but the description does not explain it.
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?
The description is a single, concise sentence that is front-loaded with the core purpose. Every word earns its place, with no repetition or unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters and no output schema, the description is too brief. It does not describe the expected outcome (e.g., payment recorded, invoice status changed, closing behavior), the prerequisites beyond invoice validation, or what the agent should expect in response. This leaves significant gaps for an agent selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with detailed descriptions for all 7 parameters, so the description does not need to explain them. It adds a small clarification that the invoice must be validated, but overall the description contributes minimal extra meaning beyond the 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 description clearly states the tool's function: 'Enregistrer un paiement (règlement) sur une facture validée' (Record a payment on a validated invoice). The verb 'enregistrer' and the resource 'facture validée' are specific, and it distinguishes from sibling tools like list_payments (viewing) and pay_supplier_invoice (supplier payments).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for recording payments on validated customer invoices, but it does not explicitly state when to use it versus alternatives like pay_supplier_invoice or how it relates to list_payments. There are no exclusions or explicit alternative recommendations, so it only provides implied usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without any details on effects (e.g., whether it modifies a locked proposal, requires specific permissions, or recalculates totals). For a mutation tool, this is insufficient.
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?
The description is a single concise sentence, front-loaded with the action and target. It contains no redundant information and is appropriately sized for a simple add-line operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential context for a mutation tool with no annotations or output schema. It does not mention response format, error scenarios, or conditions under which adding a line is valid (e.g., only for draft proposals). This is insufficient for a tool with 7 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter has a clear description (e.g., 'ID du devis', 'Quantité'). The tool description itself adds no extra semantic value beyond stating the overall purpose, which meets the baseline for high schema coverage.
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 description clearly states a specific action: 'Ajouter une ligne de produit ou service à un devis' (Add a product or service line to a quotation). It names the verb, resource (line), and target entity (devis), which distinguishes it from similar sibling tools like add_order_line or add_invoice_line.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you want to add a line to a proposal) but provides no explicit guidance on when to use this tool instead of alternatives, nor mentions any prerequisites or exclusions. It lacks direct comparison to similar 'add_line' tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without any details about side effects, permissions, whether the ticket must be open, or what happens after adding the message. This is a significant deficiency for a mutating operation.
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?
The description is a single, front-loaded sentence with no wasted words. It directly communicates the tool's purpose, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description leaves significant gaps. It does not explain expected return values, post-conditions, or any constraints like open-ticket requirements. For a write tool, this is minimally adequate but lacks essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for all three parameters, achieving 100% coverage. The tool description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
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 description 'Ajouter un message/réponse à un ticket' clearly identifies the action (add) and the resource (a message/reply to a ticket). It distinguishes itself from siblings like create_ticket, close_ticket, and assign_ticket, which address different ticket operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage: when you need to add a message to a ticket. However, it provides no explicit alternatives or when-not to use it, nor does it mention any prerequisites (e.g., ticket must exist). It falls short of offering clear guidance compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only restates the purpose (create a credit note from an invoice) without disclosing side effects on the source invoice (e.g., reversal effects on accounting), required permissions, or return behavior. The schema hints at 'contrepasser' but the description does not elaborate.
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?
Single sentence, front-loaded with the core purpose, no redundant words. Exceptionally concise without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial mutation tool with no output schema and no annotations, the description is too sparse. It lacks essential context about side effects, preconditions (e.g., invoice must be validated), and what the call returns. Given the complexity of invoice/accounting operations, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds marginal context (that the credit note is derived from an existing invoice) but does not go beyond the schema's descriptions for either 'source_invoice_id' or 'description'.
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?
Description clearly states 'Créer un avoir (facture de crédit) à partir d'une facture existante' – a specific verb (créer) + resource (credit note) + scope (from an existing invoice). This distinguishes it from sibling tools like create_invoice by explicitly requiring a source invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: you need an existing invoice ID. However, the description gives no explicit when-to-use guidance, no exclusions, and no mention of prerequisites like the source invoice's validation status. With many invoice-related siblings, clearer direction would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'create' and does not mention the order's initial status, whether the customer must already exist, or what the response contains. This is a significant gap for a mutating ERP operation.
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?
The description is a single, front-loaded sentence with no wasted words. It is as concise as possible for a purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no annotations, the one-line description is inadequate. It leaves out critical context such as default order state, required dependencies, and next steps like adding lines or validating.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all 5 parameters with 100% coverage, so the description adds no parameter-level meaning. It provides no additional context about relationships between parameters or typical usage, but the schema does the heavy lifting.
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 description uses the verb 'Créer' and identifies the resource as 'commande client' (customer order), clearly distinguishing it from sibling tools like create_supplier_order and create_proposal. It is specific and unambiguous about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when creating a new customer order, but it provides no explicit guidance on when to use this tool versus alternatives such as convert_proposal_to_order or add_order_line. There is no mention of prerequisites or follow-up steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 key behavior of returning base64, which is essential, but does not mention safety (read-only), error handling, or permissions. Lacks fuller behavioral context.
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?
The description is a single, concise sentence that front-loads the main action and includes the base64 detail. No wasted words.
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?
The tool is simple, parameters are well-documented in schema, and the description covers the return format. It could benefit from usage guidance (e.g., distinguishing from generate_document_pdf), but overall it's reasonably complete for a straightforward download operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both modulepart and original_file are described. The description adds nothing beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads/gets a document and returns base64. It implicitly distinguishes from siblings like list_documents (listing) and generate_document_pdf (creating PDFs), though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The schema mentions original_file comes from list_documents, but the description itself provides no usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses the returned content (lines, amounts, status) which is helpful, but does not mention any potential side effects, permissions, or error behavior. The read-only nature is implied but not explicitly stated.
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?
The description is a single, concise sentence that front-loads the action and resource. Every word adds value, and the list of returned details is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with one parameter and no output schema, the description covers the core purpose and return contents. However, it lacks parameter explanation and explicit usage guidance, leaving gaps in completeness for an agent selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'id' parameter with no description, and the description offers no additional meaning. It does not explain what the id represents beyond the obvious context of the report, nor any format or constraints. Schema coverage is 0%, and the description fails to compensate.
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 description clearly states the tool retrieves details of an expense report, listing specific components (lignes, montants, statut). This distinguishes it from sibling tools like list_expense_reports and create_expense_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the verb 'obtenir' and the emphasis on details, but the description does not explicitly mention when to use this tool over alternatives or any exclusions. It provides a clear context for retrieving a specific report but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. 'Vérifier' implies a read-only operation, but it does not clarify what is returned (e.g., consolidated stock vs. per-warehouse breakdown), nor how the 'par entrepôt' aspect is handled given only a product ID parameter. This ambiguity is a significant transparency gap.
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?
The description is a single, concise, front-loaded sentence that states the core function without unnecessary detail. It earns its place and is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description should explain return behavior and the warehouse scope. It says 'par entrepôt' but does not specify whether the caller must provide a warehouse ID or if all warehouses are returned. This missing context makes the tool incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the only parameter (id) with a description ('ID du produit'). The tool description does not add extra meaning about the parameter or its relationship to the warehouse dimension. Since schema coverage is 100%, baseline of 3 is appropriate.
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 description 'Vérifier le stock disponible d'un produit par entrepôt' uses a specific verb ('Vérifier') and clearly identifies the resource (product stock) and scope (by warehouse). It distinguishes from sibling tools like get_warehouse_stock and get_product by focusing on product-centric stock lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (checking stock availability) but provides no explicit guidance on when to use it over alternatives like get_warehouse_stock. No alternatives or exclusions are mentioned, leaving usage context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. "Lister" implies read-only, but the description does not explicitly state this, nor does it describe return format, potential filtering behavior, or any access requirements.
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?
The description is a single, clear sentence that efficiently states the tool's purpose without unnecessary padding or repetition.
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?
The tool is simple with one parameter and no output schema; the description adequately covers its core purpose. However, it omits any details about the nature of the contacts returned (e.g., filtered, sorted) or whether additional context is needed, leaving slight room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter id is already well-described in the schema ("ID du tiers") with 100% coverage. The description adds no additional parameter semantics beyond what the schema provides.
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 description "Lister les contacts associés à un tiers" clearly states the verb (list), resource (contacts), and scope (associated with a third party), distinguishing it from get_thirdparty (retrieves the third party itself) and list_contacts (lists all contacts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for fetching contacts of a specific third party, but offers no explicit guidance on when to use it over list_contacts or other alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description only states the action 'Lister' without explicitly confirming that it is read-only, what data it returns, or any limitations. While 'Lister' implies a read operation, it does not disclose whether there are any side effects or how the results are structured.
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?
The description is a single, concise phrase with no wasted words. It is entirely appropriate for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description simply restates the tool name in French and adds no context about what 'types de membres' entails, what the output contains, or any edge cases. For a tool with no output schema and no annotations, the description should provide more context, but it offers none beyond the name.
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?
The tool has zero parameters, and the input schema is empty. The description does not need to explain parameter semantics. Baseline of 4 applies, as there is nothing that could be added about parameters.
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 description clearly states the action ('Lister' - list) and the resource ('les types de membres' - member types), distinguishing it from sibling tools like list_members which lists members themselves, and create_member/subscribe_member. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention that this tool is appropriate for retrieving member types before creating or subscribing a member, nor does it provide any exclusions. The usage context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects, required permissions, whether the action is reversible, or what happens to related data (e.g., payment creation). This leaves significant ambiguity for an AI agent.
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?
The description is a single, concise sentence that is front-loaded with the action and target state. It contains no unnecessary words and is appropriate in size for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a state-changing tool with no annotations and no output schema, the description is too minimal. It does not explain the effects of the action, required conditions (e.g., report status), or return behavior, making it incomplete for an agent to use correctly in a workflow context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 75% of parameters with descriptions (date_paye, fk_account, mode_reglement_id), but the tool description adds no additional parameter semantics. The 'id' parameter is left undocumented, and the description does not clarify how the parameters relate to the action of marking as paid. Overall, it neither compensates for gaps nor contradicts the 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 description uses a specific verb 'Marquer' (mark) plus a resource 'note de frais' (expense report) and the target state 'comme payée' (as paid). This clearly distinguishes it from sibling tools like validate_expense_report, approve_expense_report, and refuse_expense_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to change the expense report status to paid, but it does not provide explicit guidance on when to use it versus alternatives, nor does it mention prerequisites such as prior validation or approval. There is no explicit exclusion or workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only mentions in/out stock movements and does not explain side effects like permanent stock quantity updates, creation of movement history records, permission requirements, or reversibility. This under-disclosure could lead the agent to misuse the tool.
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?
The description is a single, short sentence that immediately states the action and scope. Every word is necessary, and it is front-loaded with the key verb. This is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, a one-sentence description is inadequate. It fails to clarify what happens as a result (e.g., stock level adjustment, movement record creation), the role of 'price' for valuation, or any validation rules. The agent lacks essential contextual grounding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides, such as the qty sign conventions for entry/exit. It does not compensate or deepen understanding of any parameter.
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 description 'Effectuer un mouvement de stock (entrée ou sortie) pour un produit' clearly specifies the verb (effectuer), resource (mouvement de stock), and scope (in/out for a product). This distinguishes it from sibling read tools like get_product_stock and get_warehouse_stock.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (perform a stock movement) but offers no explicit when-to-use or when-not-to-use guidance. It does not name alternatives or emphasize that this tool writes stock data while siblings like get_product_stock only read it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the signing precondition but fails to explain side effects such as whether the original proposal is marked as converted, a new order is created, or if further validation is required. This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with precise vocabulary and zero wasted words. It efficiently conveys the core purpose and the precondition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with one parameter and no output schema, but the description leaves out important details about the outcome of the conversion (e.g., state of the original proposal, newly created order). Without annotations, this gap prevents the description from being fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the only parameter thoroughly, including the required status (2). The description adds no additional meaning beyond what the schema provides. With 100% schema coverage, the baseline of 3 applies.
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 description clearly states a specific verb ('convert') with explicit objects: a signed proposal to a customer order. This distinguishes it from sibling tools like validate_proposal and create_order, and the phrase 'devis signé' adds a key precondition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a proposal is signed and needs conversion, but it does not explicitly mention alternatives or exclusions. The schema provides the status condition, but the description itself lacks explicit guidance on when to use this tool versus create_order or validate_order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action (create) but does not disclose side effects, permissions, required prerequisites, or return behavior. This is a significant gap for a creation tool.
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?
The description is a single, front-loaded sentence with no filler. It efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter creation tool with no annotations and no output schema, the description is minimal. The schema covers parameters but lacks usage context, behavioral outcome, or prerequisites. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters have descriptions. The description adds no additional parameter meaning beyond the schema; the parenthetical event types are already covered by the typecode description.
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 description uses a specific verb ('Créer') and resource ('événement CRM') and lists possible event types (appel, réunion, email, action commerciale), clearly distinguishing it from sibling tools like list_agenda_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 vs alternatives, though it is implied as the only create-agenda tool among siblings. The description does not state exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action without disclosing side effects, prerequisites (e.g., validated quote/order), whether the invoice is created as draft or validated, or what response to expect.
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?
The description is a single, front-loaded, concise sentence that directly communicates the tool's purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a create operation with 5 parameters and no output schema. It lacks essential context about prerequisites, response format, side effects, and parameter details beyond a vague reference to source and percentage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%. The description adds minimal context (origin_type values are 'devis' or 'commande', deposit_percent is a percentage) but does not explain the remaining parameters (date, payment_terms_id). It fails to fully compensate for the low schema coverage.
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 description uses a specific verb ('créer') and resource ('facture d'acompte') and clearly states the source ('depuis un devis ou une commande'). It distinguishes this tool from siblings like create_invoice by specifying it creates deposit invoices from quotes or orders.
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?
The description implies when to use this tool: when a deposit invoice is needed from a quote or order. It provides clear context but does not explicitly state alternatives or exclusions (e.g., when to use create_invoice instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It only states the creation act and the source entity (order), without describing side effects (e.g., order status changes, inventory updates), required permissions, or what the response looks like. This is a significant gap for a create tool.
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?
The description is a single, focused sentence that clearly conveys the tool's purpose. It is appropriately sized, front-loaded, and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no annotations, and no output schema. The description is minimal and does not explain the return value, the shipment-creation workflow (e.g., draft vs. validated), or how it relates to sibling tools like validate_shipment and deliver_shipment. While the schema covers parameter meanings, the description lacks operational context needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents 5 of 6 parameters with descriptions (e.g., 'ID de la commande source', 'Date de livraison ISO 8601'), and coverage is 83%. The tool description adds no extra meaning beyond the schema, so the baseline of 3 is appropriate. The note_public parameter lacks a description, but the schema gap is not compensated by the description.
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 description clearly states the tool's function: 'Créer un bon de livraison/expédition depuis une commande' (create a delivery note/shipment from an order). It uses a specific verb ('Créer') and resource ('bon de livraison/expédition') and distinguishes it from sibling tools like validate_shipment or deliver_shipment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'depuis une commande' (from an order), indicating the input source. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites (e.g., order must exist) or exclusions. This falls into 'implied usage' with no clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states that it lists invoices and provides no information about return format, pagination, authentication, or side effects. It implies a read-only operation but doesn't confirm it.
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?
The description is a single, clear sentence with no redundant information. It is appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description explains the core functionality but omits details about the return structure or any filtering/pagination behavior. While adequate for a basic list, it could be more complete given the lack of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the `id` parameter with a description. The tool description reinforces that the ID refers to a third party but adds no new meaning beyond the schema. This aligns with the baseline score for high schema coverage.
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 description clearly states the action ('Lister') and resource ('factures d'un tiers spécifique'), making the tool's purpose unambiguous. It distinguishes from related tools like `get_invoice` (single invoice) and `list_invoices` (all invoices) by specifying the third-party scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving invoices for a specific third party, but it doesn't explicitly state when to use it over alternatives like `list_invoices` or `get_thirdparty_orders`. No exclusions or alternative tools are mentioned, leaving usage to be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only restates the tool name in French with no additional behavioral details. It doesn't disclose the return format (e.g., list of journal codes and labels), any sorting/filtering behavior, or whether it is strictly a read-only operation beyond the implied 'list' action.
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?
The description is a single, short sentence that communicates the tool's purpose with no wasted words. It is appropriately sized for a simple no-parameter tool and is front-loaded with the essential action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter list tool, the description is minimally adequate for selection and invocation. However, without an output schema, it doesn't specify what the response contains (e.g., journal codes, names, or additional metadata). The description could have added return-value context to be more complete, but for a simple listing operation, it suffices for basic usage.
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?
The input schema has zero parameters, so there is nothing to explain. Per the rubric, a baseline of 4 is appropriate for a zero-parameter tool. The description adds no parameter-specific info because none exist.
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 description clearly states 'Lister les journaux comptables' (list accounting journals) and provides examples of journal types (Ventes, Achats, Banque, OD...), making the tool's specific purpose unmistakable even among many list-related siblings like list_accounting_accounts. It uses a specific verb and resource, fully distinguishing this tool from others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or scenarios where a different tool would be more appropriate. For example, it doesn't clarify whether this tool also covers general ledger entries or only journal master data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries all behavioral burden. It only states the core function and gives no details about read-only safety, return format, pagination, filtering, or error conditions. 'List' implies a read operation, but this is not disclosed.
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?
The description is a single, short sentence in French that directly states the action and target. No extraneous words or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter list tool, the description conveys the basic purpose, but with no output schema and no behavioral details (e.g., whether it returns empty lists, how records are sorted), the agent is left with some ambiguity. Adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents thirdparty_id as 'ID du client' with 100% coverage. The description's 'pour un client' merely echoes this, adding no new semantic detail about formats, constraints, or behavior.
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 description uses a specific verb 'Lister' (list) and identifies the resource as 'avoirs/remises exceptionnelles' (exceptional credits/discounts) for a customer. It clearly distinguishes from sibling tools like get_thirdparty_discount by specifying 'exceptionnelles'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to fetch exceptional discounts for a given customer, but it does not explicitly state when to use it over alternatives such as get_thirdparty_discount or list_invoices. No exclusions or alternative conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds value by disclosing the status code semantics (1=Brouillon to 5=Annulé), but it does not state that the operation is read-only, what the default scope is, or how results are returned. The read-only nature is only implied by 'Lister'.
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?
The description is two concise sentences, front-loaded with the purpose and followed by essential status reference. There is no redundant content or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, this is adequate but has gaps: it does not mention default filtering behavior (e.g., whether all statuses are returned by default), pagination/limit defaults, or how parameters interact. No output schema is provided, so more context would be needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, but the description compensates partially by providing an enumerated mapping for the status parameter. However, it does not explain the 'limit' or 'sqlfilters' parameters, leaving their meaning and usage unclear.
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 description states 'Lister les demandes de congés' which is a specific verb+resource, clearly indicating it lists leave requests. This distinguishes it from sibling tools like get_leave_request (single fetch), create_leave_request (creation), and list_leave_types (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as get_leave_request or list_leave_types. The name implies listing, but there is no explicit context or exclusions, leaving the agent without clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the action 'approuver' (approve) but does not disclose side effects, prerequisites beyond validation, permission requirements, or what happens to the report's state. The verb implies a state change but offers no further transparency, leaving significant gaps.
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?
The description is a single concise sentence, 'Approuver une note de frais validée', which is front-loaded with the verb and resource. Every word contributes meaning, making it highly efficient with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is minimally viable: it conveys the action and a key condition (validated). However, it lacks behavioral details and does not explain what information the 'id' should refer to, so the agent may still have questions. This is adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'id' parameter or provide any guidance on how to specify it. While the tool name makes it plausible that 'id' is the expense report ID, the description does not compensate for the lack of schema details. With only one parameter, adding a brief note would have been easy, but it is absent.
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 description uses a specific verb 'Approuver' (approve) with a clear resource 'note de frais' (expense report) and adds the qualifier 'validée' (validated), which distinguishes it from sibling tools like validate_expense_report and refuse_expense_report. It clearly states what the tool does and the target object.
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?
The qualifier 'validée' provides clear context that this tool is for expense reports that have already been validated, implying it should be used after validation. No explicit alternatives or exclusions are given, but the condition 'validated' itself serves as a usage guideline. This is clear context without formal exclusions, matching a score of 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It says the action is destructive, but it does not mention reversibility, side effects on invoice totals, permissions, or error conditions. For a delete operation, this is a significant gap.
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?
The description is a single, concise sentence that immediately conveys the action and target. There is no redundancy or filler, and it is structured with the verb and object first.
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 simple delete operation with two fully described parameters, the description is largely complete. It clearly states the scope (draft invoice) and the parameters are self-explanatory. However, it does not mention return values or error handling, which could be useful but are not critical for a basic delete tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides clear descriptions for both parameters (line_id and invoice_id) with 100% coverage. The description adds no extra meaning beyond the schema, so it meets the baseline but does not enhance parameter understanding.
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 description 'Supprimer une ligne d'une facture brouillon' clearly states a specific action (delete), a resource (invoice line), and a context (draft invoice). This distinguishes it from sibling tools like add_invoice_line and update_invoice_line.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for removing lines from draft invoices but does not explicitly explain when to use it over alternatives like update_invoice_line. The draft-invoice constraint is stated, but there is no explicit when-not or comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Aucune annotation n'est fournie, la description doit donc tout porter. Le verbe 'Obtenir' suggère une opération en lecture, mais cela n'est pas explicite. Aucune information sur les effets de bord éventuels, les autorisations requises ou la portée des données retournées.
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?
Une phrase unique, concise et sans fioritures. Chaque mot apporte une information utile (action, objet, qualificatif 'actif', contexte SYSCOHADA).
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?
Pour un outil sans paramètre ni schéma de sortie, la description est suffisamment complète quant à l'objet. Toutefois, elle ne précise pas le format de retour ni si un prérequis comme l'initialisation SYSCOHADA est nécessaire, ce qui pourrait aider un agent.
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?
L'outil ne comporte aucun paramètre, la baseline est donc de 4. La description ajoute du sens en précisant que le retour concerne le plan comptable actif et les correspondances SYSCOHADA, ce qui clarifie l'objet de la réponse.
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?
La description utilise un verbe d'action précis ('Obtenir') et identifie clairement la ressource ('plan comptable actif' et 'correspondances SYSCOHADA'). Elle se distingue des outils frères similaires comme list_accounting_accounts en précisant 'actif' et 'correspondances'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Aucune indication sur quand utiliser cet outil par rapport à des alternatives telles que list_accounting_accounts ou get_accounting_config. La description ne fournit ni contexte d'utilisation, ni exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It only states 'Obtenir les details', which is essentially a direct translation of the tool name, and does not disclose any additional traits such as potential errors, return format, or authorization requirements.
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?
The description is a single, concise sentence with no filler. It is front-loaded and to the point, making it easy for an agent to parse.
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 simple get-by-id tool with one parameter and no output schema, the description is sufficient. It clearly identifies the resource type (supplier order), and while it doesn't detail return contents, that is not strictly necessary for a straightforward getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is fully described with 100% coverage, so the baseline is 3. The tool description adds no additional meaning about the 'id' parameter beyond the schema's own description.
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 description clearly states the tool's purpose: obtaining the details of a supplier order. The verb 'Obtenir' and resource 'détails d'une commande fournisseur' are specific and distinguish it from sibling tools like list_supplier_orders and get_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the tool takes an id and returns details, so it's for when you have a specific supplier order ID. However, it does not explicitly mention when to use this versus list_supplier_orders or provide exclusions/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 clarifies the scope (global discount, customer/supplier) but does not explicitly state that the operation is read-only, what the return format is, or whether any side effects occur. For a getter, the read-only nature is implied by the name, but the description adds no explicit safety or behavioral context.
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?
The description is a single, concise sentence that is front-loaded with the verb 'Obtenir'. Every word earns its place, and there is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but the description does not mention the return value or format (e.g., a number representing a percentage). It also does not differentiate from the sibling get_thirdparty_price_level, which could cause confusion. More detail about what 'global discount' means and what the agent should expect in response would increase completeness.
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?
The input schema only has thirdparty_id with no description, so the description's mention of 'd'un client ou fournisseur' provides meaningful context that the ID represents a customer or supplier. It helps the agent understand the parameter's role and domain, partially compensating for the schema's 0% description coverage.
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 description clearly states the tool retrieves the global discount for a customer or supplier ("Obtenir la remise globale d'un client ou fournisseur"). This specific verb+resource combination distinguishes it from siblings like set_thirdparty_discount and get_thirdparty_price_level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the verb 'get' and the presence of a sibling 'set_thirdparty_discount', but the description does not explicitly mention when to use this tool or why it should be preferred over alternatives. No exclusions or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden for behavioral disclosure. It adds useful context that the tool returns standard accounts if the SYSCOHADA chart is not initialized. However, it does not mention permissions, side effects, or any response details, though as a list operation this is less critical.
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?
The description is two short sentences, front-loaded with the primary purpose and immediately followed by a relevant edge case. Every sentence adds value with zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema. The description covers the main purpose and an edge case, but it omits the limit parameter's semantics, leaving a gap in completeness. The description is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter 'limit' with no description (0% coverage). The description does not mention this parameter at all, leaving the agent to infer its meaning solely from the parameter name. The description fails to compensate for the lack of schema documentation.
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 description clearly states it lists the accounts of the SYSCOHADA chart of accounts, with a specific verb ('Lister') and resource ('comptes du plan comptable SYSCOHADA'). It also adds a behavioral edge case (returns standard accounts if not initialized), which helps distinguish it from other accounting list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about what the tool does, but it does not explicitly state when to use it compared to siblings like get_chart_of_accounts or list_accounting_journals. No exclusions or alternatives are mentioned, so the usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only adds scope distinction (individual vs. third-party contacts) and does not mention pagination behavior, default limits, ordering, output format, or whether the operation is read-only. This is a significant gap for a listing tool with no annotations.
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?
The description is a single, concise sentence that immediately states the tool's purpose without any filler. It is well-structured and front-loaded with the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the description covers the core purpose but lacks details on return values, pagination, and comparison with related tools like get_thirdparty_contacts. It is minimally adequate but does not provide enough context for an agent to fully understand the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% with page and limit lacking descriptions. The description does not compensate by explaining any parameter usage or providing examples. It adds no semantic value beyond what the schema already covers for sqlfilters and thirdparty_id, leaving page and limit undefined.
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 description clearly states that the tool lists individual contacts (natural persons) distinct from third parties/companies. It uses a specific verb ('Lister') and identifies the resource ('contacts individuels'), and it distinguishes itself from sibling tools like list_thirdparties and get_thirdparty_contacts by clarifying the type of contacts included.
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?
The description provides clear context for when to use the tool: when listing natural persons rather than organizations. However, it does not explicitly name alternative tools (e.g., list_thirdparties) or provide when-not-to-use conditions, leaving some room for ambiguity in complex scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates the status code mapping already present in the schema. It does not mention read-only behavior, pagination details, potential side effects, or any other non-obvious traits, leaving the agent to infer these from the tool name and parameter schema.
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?
The description is two sentences long, with the first sentence front-loading the core purpose and filter options. The second sentence provides the status code mapping, which is useful context even if it overlaps with the schema, resulting in no wasted words.
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 straightforward list tool with five well-documented parameters and no output schema, the description sufficiently covers the purpose and filter capabilities. However, it does not mention pagination behavior beyond the schema's 'limit' default, nor explain the sqlfilters syntax beyond the schema example, leaving minor gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of all five parameters with descriptions, setting a baseline of 3. The description's mention of 'statut, tiers, date' is essentially a summary of the schema's parameter descriptions and adds no new meaning beyond what the schema already provides.
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 description uses the specific verb 'Lister' (list) with the resource 'factures' (invoices) and explicitly mentions advanced filters on status, third party, and date. This clearly identifies the tool's purpose and implies customer invoices, distinguishing it from the sibling list_supplier_invoices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'avec filtres avancés' implies the tool is for listing invoices with filtering, but no explicit guidance is given about when to use it versus alternatives like list_supplier_invoices or get_invoice. There are no when-not or alternative recommendations, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only says 'update' without disclosing whether it overwrites existing values, whether fields are optional, or what happens on success/failure. This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action. No unnecessary words or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 optional parameters, no annotations, and no output schema, the description lacks critical context. It doesn't explain return values, behavior when fields are omitted, or any potential side effects. The minimal description is insufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% parameter descriptions, so the baseline is 3. The description adds a few examples (address, phone, email, legal numbers) but doesn't provide additional semantics beyond the schema's field descriptions.
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 description clearly states the tool's purpose with a specific verb ('Mettre à jour') and resource ('les informations de la société'), listing example fields. It is easily distinguishable from the sibling 'get_company_info' and other configuration 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?
The description provides clear context: this tool is for updating company information. While it doesn't explicitly mention alternatives or when-not-to-use scenarios, the naming and description make it unambiguous compared to the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that the action transitions the expense report to an 'awaiting approval' state via 'submit for approval', which adds context beyond just saying 'validate'. However, it does not mention permissions, irreversibility, or further side effects.
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?
The description is a single, front-loaded sentence that clearly states the verb and resource, with a helpful explanatory clause. It is concise and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is minimally adequate. It tells the primary purpose and adds the submission context, but it does not clarify the resulting status, nor does it mention the difference from 'approve_expense_report' or any prerequisites. This leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the single required parameter 'id'. While it is likely obvious that 'id' refers to the expense report ID, the description adds no parameter semantics beyond the raw schema, and the low coverage is not compensated.
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 description clearly states the action ('Valider une note de frais' - validate an expense report) and adds the parenthetical 'la soumettre pour approbation' (submit it for approval), which clarifies the exact purpose and distinguishes it from the sibling 'approve_expense_report' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to submit an expense report for approval), but it does not explicitly contrast this with alternatives like 'approve_expense_report' or state when not to use it. The parenthetical gives context but lacks explicit exclusions or alternative pointers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 proposal is marked as refused or expired, but does not mention side effects, reversibility, permissions, or return behavior. For a mutation tool, this is insufficient transparency.
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?
The description is a single, front-loaded sentence with no wasted words. It conveys the essential purpose and key constraint ('sans conversion') efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple close operation, the description provides the core semantics but omits workflow context (e.g., whether the proposal must be in a certain state before closing). It is minimally viable but lacks details that would help the agent decide when closing is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (id, note, status) is already documented. The description adds minimal extra meaning, only reinforcing that status corresponds to refusal or expiry, which is already in the 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 description uses a specific verb ('Clôturer') with a clear resource ('un devis') and specifies the exact outcomes: 'marquer comme refusé ou expiré sans conversion'. This distinguishes it from sibling tools like convert_proposal_to_order and validate_proposal.
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?
The phrase 'sans conversion' implies an alternative action (conversion to order) and indicates this tool is for closing without converting. However, it does not explicitly name alternatives or state when not to use it, so it falls short of full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It does not disclose any behavioral traits beyond the basic action, such as permissions, duplicate handling, required fields (though schema lists name), or response format. This is a mutation tool, so more context is needed.
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?
The description is a single, concise sentence in French, front-loaded with the verb and resource. Every word earns its place, and it is efficiently sized for the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 15 parameters, no annotations, and no output schema, the description is minimal. It does not mention the required 'name' field, expected response, or any side effects. While the schema covers parameters, the description lacks broader context for a complex create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description. The tool description adds no parameter information beyond what the schema already provides, so the baseline score of 3 applies.
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 description clearly states the action ('Créer' = create) and the resource ('tiers' = third party), specifying it covers client, prospect, or supplier. This clearly distinguishes it from sibling tools like update_thirdparty or get_thirdparty.
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?
The context is clear: the tool is for creating new third parties. While it does not explicitly mention alternatives or exclusions, the 'create' verb strongly implies use for new records, and update_thirdparty exists for modifications, providing implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. The verb 'obtenir' (get) implies a read-only operation, and 'détails complets' indicates the response contains the full proposal record. However, it doesn't disclose potential error behavior (e.g., missing ID), authentication requirements, or any side effects. The description goes slightly beyond the tool name but still lacks depth.
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?
The description is a single, front-loaded sentence: 'Obtenir les détails complets d'un devis.' It contains no filler and precisely communicates the core function, making it efficient and well-structured for a simple get tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID with full schema and no output schema, the description is minimally sufficient: it states the action, resource, and scope. However, it does not reference the broader proposal workflow (e.g., list_proposals to find IDs, or get_thirdparty_proposals) or clarify how 'complete details' differs from other proposal representations. Given the wide sibling list, a sentence pointing to list_proposals as the discovery mechanism would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the only parameter 'id' with 100% coverage ('ID du devis'), and the description doesn't add additional parameter-level detail (e.g., format, required flag, or how to find the ID). Baseline 3 applies because the schema fully documents the parameter.
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 description uses the specific verb 'obtenir' (get) with the resource 'devis' (proposal), clearly distinguishing it from sibling tools like list_proposals, create_proposal, or validate_proposal. The phrase 'détails complets' clarifies the scope, so an agent can differentiate this from a list or summary operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description doesn't explicitly state when to use this tool versus alternatives, the tool name get_proposal and the required 'id' parameter imply it's for fetching a single proposal. This implied usage is sufficient for an agent to select it when a proposal ID is known, but it doesn't mention alternatives like list_proposals for searching. No explicit exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosure. The verb 'Obtenir' suggests a read-only operation, but the description does not explicitly confirm no side effects, nor does it mention error handling, authentication, or response details beyond 'complete details.' This is minimal but not misleading.
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?
The description is a single concise sentence that is immediately understandable. Every word adds value, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description covers the basic purpose, but without an output schema it leaves the return structure undefined. A brief note on what 'complete details' includes or what 'third party' refers to in this context would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single 'id' parameter. The description repeats that the ID is used but adds no new semantic details such as format, examples, or behavior for invalid IDs.
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 description uses a specific verb ('Obtenir') and resource ('détails complets d'un tiers') and clarifies the lookup key (by its ID). It clearly distinguishes this from sibling tools like list_thirdparties or get_thirdparty_invoices by specifying the full-record retrieval via ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific third-party ID is known and full details are needed, but it does not explicitly mention alternatives or exclusions. No when-not-to-use guidance is provided, so the implied context is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the core behavior (listing orders for a third party) but does not disclose additional behavioral details such as pagination, order statuses included, or whether it only returns confirmed orders. This is adequate but not rich.
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?
The description is a single, concise sentence that is front-loaded with the verb and resource. Every word earns its place, with no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is minimally sufficient. However, it does not specify the return structure or any filtering nuances, which could be valuable given the absence of an output schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage: the single parameter 'id' is described as 'ID du tiers'. The description adds no further parameter context, but since schema coverage is high, the baseline of 3 applies.
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 description 'Lister toutes les commandes d'un tiers' uses a specific verb ('Lister') and resource ('commandes d'un tiers'), clearly distinguishing it from sibling tools like list_orders (which lists all orders) and get_thirdparty (which retrieves third-party details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving orders for a specific third party, but it does not explicitly state when to prefer this over alternatives such as list_orders or get_thirdparty_invoices. It lacks explicit exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. The verb 'obtenir' implies a read-only retrieval, and the listing of fields (price, stock, description, photos) gives some insight into the response content. However, it does not explicitly state safety, error behavior, or format completeness, leaving some gaps.
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?
The description is a single, front-loaded sentence that directly communicates the tool's purpose and key details. It contains no superfluous words and is efficiently structured.
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 simple get-by-ID tool with one parameter and no output schema, the description provides sufficient context by listing the types of details returned. It could be more complete by explicitly stating it operates on a single product by ID, but it is adequate for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter 'id' with 'ID du produit' at 100% coverage. The description adds no additional meaning about the parameter, so it earns the baseline score of 3.
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 description specifies a clear verb ('obtenir' = get) and resource ('un produit' = a product), and lists the exact details returned (price, stock, description, photos). This distinguishes it from sibling tools like get_product_stock or get_product_prices, which return only specific subsets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need all product details, but it does not explicitly mention when to use this tool versus alternatives like get_product_stock or list_products. There is no exclusions or alternative guidance, so it falls short of clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It indicates a read operation via 'Obtenir' and adds that tasks are included, but it does not disclose return format, error behavior, or whether task details are nested or complete. Some useful context is present, but significant gaps remain.
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?
The description is a single, front-loaded French sentence with no filler or repeated information. Every word contributes to the tool's purpose, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter and no output schema. The description sufficiently states that it returns project details and tasks, which is enough for an agent to select and invoke correctly. However, 'details' remains somewhat vague, and the exact return structure is unspecified, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single parameter 'id' with 100% schema description coverage ('ID du projet'). The description adds no additional parameter semantics beyond what the schema already states, so the baseline of 3 applies.
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 description uses a specific verb 'Obtenir' and names the resource 'un projet' along with its tasks, which clearly distinguishes it from sibling tools like list_projects. It precisely communicates what the tool retrieves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when needing details of a single project and its tasks, but it does not explicitly contrast with list_projects or other alternatives, nor does it mention exclusions. Usage context is only implicit through the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It indicates a retrieval operation ('Obtenir') and its purpose, but does not disclose return format, error conditions, or the relationship to set_thirdparty_price_level. For a simple read tool, this is minimal but not severely lacking.
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?
The description is a single, front-loaded sentence that states what the tool does and why it is used. Every word adds value; there is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description does not mention the return value format or behavior (e.g., what a price level looks like). While 'niveau tarifaire' is self-explanatory, the lack of details about the response or related nuances leaves an incomplete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description does not directly explain 'thirdparty_id'. It uses 'client' (customer) which partially clarifies that the ID refers to a customer, but 'thirdparty_id' is broader in ERP context, creating potential ambiguity. The description does not compensate for the missing schema documentation.
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 description clearly states the action ('Obtenir' / get) and the resource ('niveau tarifaire d'un client' / customer's price level), with an explicit purpose: 'pour savoir quel prix lui appliquer'. This distinguishes it from the sibling 'set_thirdparty_price_level' as the read/getter counterpart.
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?
The description provides clear context for when to use this tool: to determine the price level to apply to a customer. It does not explicitly mention alternative tools (e.g., set_thirdparty_price_level or get_thirdparty_discount) or exclusions, but the purpose statement implies the read-only use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full transparency burden. It merely states the action and scope; it does not disclose whether drafts/validated proposals are included, pagination behavior, or permission requirements. This is minimal behavioral disclosure.
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?
The description is a single, concise French sentence with no redundant words. It front-loads the action and object clearly, achieving maximum economy.
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 simple one-parameter list tool without output schema, the description covers the core purpose and required input. It does not mention return format or filtering nuances, but the tool name and description imply a list of proposals, which is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the sole parameter 'id' as 'ID du tiers', and the description echoes this without adding extra meaning. With 100% schema coverage, the baseline of 3 is appropriate.
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 description uses the active verb 'Lister' (list) with a specific resource 'devis/propositions d'un tiers', clearly identifying the operation. It distinguishes itself from sibling tools like list_proposals (general list) and get_proposal (single proposal) by specifying the third-party scope.
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?
The phrase 'd'un tiers' provides clear context that this is for all proposals associated with a given third party. However, it does not explicitly mention alternatives or exclusions, so it lacks the explicit when/when-not guidance needed for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides minimal behavioral context—only that results include the current balance. It does not disclose potential permissions, filtering defaults (though the status parameter is described in the schema), or response structure, leaving a transparency gap.
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?
The description is a single concise sentence that directly conveys the tool's purpose without redundancy or extraneous details.
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 simple list operation with one optional parameter, the description adequately conveys the core functionality and the returned data (current balance). Some details like response format or pagination are absent, but given the low complexity, the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter (status) is fully described in the schema with good coverage, so the description does not need to add parameter semantics. It adds no extra meaning beyond the 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 description clearly states the tool lists the company's bank accounts with their current balance, using a specific verb and resource. It distinguishes from related tools like list_accounting_accounts (chart of accounts) and list_bank_transactions (transactions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to retrieve bank accounts and their balances, but it does not explicitly mention alternatives or exclusions. Sibling tools include other list operations, so context suggests this is the dedicated tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the basic action. It does not disclose any behavioral details such as whether the list is sorted, whether only active currencies are returned, or any access requirements, leaving the agent with limited insight.
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?
The description is a single concise sentence with no redundant information. It is front-loaded and easy to parse.
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?
Given the tool's simplicity (no parameters, no output schema), the description is adequate but minimal. It could benefit from specifying the format or source of the currency list, but it is not misleading and covers the core purpose.
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?
The tool has 0 parameters, and the schema is trivially covered. The description adds no parameter-level detail, but since there are no parameters, this is acceptable and aligns with the baseline for 0-parameter tools.
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 description clearly states the action (list) and the resource (currencies in Dolibarr), making its purpose unambiguous. It is specific enough to distinguish from sibling tools like list_countries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a simple list operation, but it does not explicitly state when to use it or mention any alternatives. No exclusions or preconditions are provided, which is a minor gap for a zero-parameter tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral outcomes: making the order official and generating an order number. However, it does not mention whether validation is irreversible, any side effects, or preconditions beyond 'draft', so transparency is adequate but incomplete.
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?
The description is a single, concise sentence that conveys purpose and outcome without unnecessary words. It is well-structured and front-loaded with the action verb.
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 simple tool with one parameter and no output schema, the description is largely complete: it explains the effect of validation and the generation of an order number. It could be more complete by explicitly stating that only draft orders are eligible, but overall it provides sufficient context for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a description for the sole parameter 'id' (ID of the order), giving 100% schema coverage. The tool description adds no further meaning or constraints about this parameter, so the baseline score of 3 applies.
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 description clearly states the tool validates a draft order, making it official and generating an order number. It uses a specific verb and resource, and the phrase 'draft order' distinguishes it from other validate_* tools like validate_invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for draft orders by explicitly mentioning 'commande brouillon', but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it reference alternatives such as validate_invoice or convert_proposal_to_order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what is listed, but does not explicitly state that it is a read-only operation, nor does it mention any sorting, pagination, or potential side effects. For a list tool, this is a notable gap.
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?
The description is a single, front-loaded sentence that conveys the essential information without any waste. It also includes useful examples of what payment terms look like.
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 a simple parameterless list operation with no output schema, the description fully covers what the tool returns. Examples clarify the contents, making it complete for its complexity level.
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?
The tool has zero parameters, so the description does not need to explain any. The baseline of 4 applies here, as there is no parameter detail to add.
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 description uses a specific verb 'Lister' (list) with a clear resource 'conditions de paiement configurées' (configured payment terms). Examples of terms are provided, making it easy to distinguish from sibling tools like list_payments or list_payment_methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when you need to see the configured payment term options. However, it does not explicitly mention alternatives or state when not to use it, despite there being similar list tools (list_payment_methods, list_payments) that could confuse an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does mention that the corresponding invoice is generated automatically, which adds useful context. However, it does not disclose side effects (e.g., order status change), whether the operation is idempotent, or any permission requirements.
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?
The description is a single concise sentence with the verb and object front-loaded. Every word adds value, with no repetition or extraneous content.
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 straightforward conversion tool with one parameter and no output schema, the description adequately covers the core behavior. It lacks details on return values or post-conditions (e.g., what happens to the order), but is sufficiently complete for typical use.
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?
The sole parameter 'id' is fully described in the schema as 'ID de la commande', so coverage is 100% and baseline is 3. The description adds meaning by specifying the order must be 'validée', which is a valuable constraint not present in the 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 description uses the specific verb 'Facturer' (to invoice) and identifies the exact resource 'commande client validée' (validated customer order). This clearly distinguishes it from related tools like create_invoice or convert_proposal_to_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for validated orders ('commande client validée') but does not explicitly state when to use this tool versus alternatives like create_invoice or how it relates to order status. The context is clear but exclusions or alternative guidance are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of behavioral disclosure. It clearly labels the operation as read-only via 'Lire', indicating no destructive side effects. However, it does not describe permissions, response format, or any handling of unset configuration, which would provide fuller transparency.
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?
The description is a single, focused sentence that front-loads the action ('Lire toute la configuration comptabilite') and then provides a concise list of covered areas. No filler, redundancy, or unnecessary technical detail.
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 no-parameter, read-only tool with no output schema, the description adequately covers scope and purpose. It names the main configuration areas, but does not address potential complexities like multi-company settings or localization, leaving a slight completeness gap.
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?
The tool has zero parameters, so the input schema is empty, giving a baseline of 4. The description adds semantic context by listing the configuration domains included, which helps the agent infer what data will be returned, though it is not parameter-specific.
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 description uses the specific verb 'Lire' (to read) and explicitly names the resource 'toute la configuration comptabilite' with enumerated domains (comptes par defaut, mode TVA, plan comptable, numerotation, export). This distinguishes it from sibling configuration tools like configure_vat_mode and configure_invoice_numbering, which are write operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'Lire' implies a read context, but the description does not explicitly contrast with the many configure_* sibling tools or mention when to prefer this over specific getters like get_chart_of_accounts or get_vat_report. Guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of disclosing behavioral traits. The verb 'Obtenir' implies a read-only operation, and the mention of 'informations complètes' indicates a comprehensive return, but it does not disclose potential edge cases (e.g., required permissions, response format, or whether it can fail). It adds some transparency but lacks depth.
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?
The description is a single, focused sentence that immediately states what the tool does. It is front-loaded with the action and resource, and every word adds value. No fluff or redundancy.
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?
Given the simplicity (zero parameters, no output schema), the description is fairly complete. It lists key fields that will be returned, which is helpful. However, it could mention potential limitations (e.g., whether 'complete' includes all settings or only basic info) and any required authentication, but these are minor gaps for a simple getter.
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?
The input schema has zero parameters, so the baseline is 4. The description does not need to explain any parameters, and it instead adds value by outlining the expected return fields (name, address, SIRET/NINEA, TVA, logo), which partially compensates for the lack of an output 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 description uses a specific verb 'Obtenir' (get) with a concrete resource ('informations complètes de la société configurée dans Dolibarr') and lists example fields (name, address, SIRET/NINEA, VAT, logo). It clearly distinguishes from sibling tools like update_company_info and get_setup_values by focusing on the configured company details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied rather than explicitly stated: the description indicates this fetches complete company configuration, but it does not explicitly say when to use it instead of alternatives like get_setup_values or when not to use it. There is no exclusion guidance, but the purpose is evident from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. 'Lister' implies a non-destructive read operation, and the mention of status conveys the returned data. However, it does not explicitly state side-effect-freeness, authorization requirements, or whether any filtering behavior beyond the status parameter exists.
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?
The description is two short sentences, front-loaded with the core action and resource, followed by the practical value. No filler or redundancy.
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?
Given the tool's simplicity, the description and schema together cover the essential aspects: what it lists, the optional filter, and why it's useful. It does not describe the return format or error conditions, but for a straightforward list operation, the current information is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single 'status' parameter, describing its values and default. The description adds no extra semantic detail beyond what the schema provides, so the baseline 3 is appropriate.
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 description uses a specific verb 'Lister' with a clear resource 'tous les modules Dolibarr' and their status, making its purpose unmistakable. It distinguishes itself from sibling tools by focusing specifically on module enumeration, which is unique among the provided siblings.
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?
The description provides a clear usage context: 'Essentiel pour savoir quelles fonctionnalités sont disponibles' tells the agent when this tool is useful. It does not name alternatives or explicit when-not-to-use scenarios, but for a simple list tool this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It mentions filtering and pagination, and the verb 'Lister' implies a read-only action, but it does not explicitly state read-only, return format, or default behavior beyond schema. Some gaps remain.
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?
Two concise sentences, front-loaded with the core purpose, followed by capability highlights. Every word earns its place without redundancy.
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?
Given the 6-parameter tool with full schema coverage and no output schema, the description adequately explains the core listing/searching behavior and key features. It omits explicit return shape details and guidance versus get_thirdparty, but it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds a high-level note about name search and SQL filters but does not provide additional meaning beyond what the schema already documents for each parameter.
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 description clearly states the tool lists and searches Dolibarr third parties (customers, prospects, suppliers). The verb 'Lister et rechercher' plus the resource and type enumeration makes it distinct from sibling tools like get_thirdparty.
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 provides clear context by mentioning search by name, SQL filters, and pagination, which indicates when it is useful. However, it does not explicitly state alternatives or when not to use it (e.g., for a single third party, use get_thirdparty).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 a key side effect: PDF generation and attachment. However, it does not mention permissions, whether the invoice status changes, or delivery confirmation.
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?
Two concise sentences with no fluff. Purpose is front-loaded and the additional detail about PDF generation is relevant.
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?
The description is fairly complete for a simple send tool: it states the action and the key side effect. However, it omits any prerequisites (e.g., invoice must be validated) or post-conditions (e.g., invoice marked as sent). Given no annotations, a bit more context would be helpful, but the schema covers parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: all four parameters have descriptions in the schema. The description adds no additional parameter semantics beyond what the schema already provides, so baseline 3 applies.
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 description is clear and specific: 'Envoyer une facture par email au client' (send an invoice by email to the customer) and it mentions generating the Dolibarr PDF. This distinguishes it from sibling tools like send_mailing or validate_invoice.
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?
The description implies use for sending an individual invoice email, but it does not explicitly state when not to use it or name alternatives. Context is clear, but no exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds the useful limitation that only draft invoices can be modified, but it does not mention other potential behaviors such as permission requirements, side effects on totals, or error handling. This is a minimal but non-trivial disclosure.
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?
The description is a single, efficient sentence that immediately states the verb, object, and key constraint. There is no wasted wording, and the most critical information (draft-only) is included without elaboration.
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?
Given the low complexity of this tool (simple line update with fully described params), the description is largely complete. It includes the essential draft-only restriction and the purpose. It lacks details about return values or error behavior, but for a straightforward update tool with well-documented schema, it covers the main context adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all 7 parameters with 100% coverage, and the description adds no additional parameter-level meaning. Since the schema already provides the definitions, the baseline of 3 is appropriate; the description does not need to compensate for missing schema information.
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 description clearly states 'Modifier une ligne existante d'une facture' (modify an existing invoice line), which is a specific verb and resource. It distinguishes itself from siblings like add_invoice_line and delete_invoice_line by specifying modification of an existing line, and adds the scope 'draft only'.
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?
The description includes the constraint 'brouillon seulement' (draft only), which tells the agent when this tool is applicable and implicitly excludes non-draft invoices. However, it does not explicitly name alternative tools like add_invoice_line for adding lines, so it provides clear context but no exclusions beyond the draft restriction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The word 'Obtenir' implies a read-only operation, and the description adds what details are returned (lines, status, deliveries). It does not explicitly state side-effect-free behavior, permissions, or error cases, but for a simple getter, this is minimally sufficient.
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?
The description is a single, concise sentence with the verb and object front-loaded. Every word earns its place, listing the key return elements without unnecessary elaboration.
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 a simple getter with one parameter and no output schema, the description is complete: it states the action, the resource, and the types of information included. It gives an agent enough context to select this tool confidently, even without formal annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameter (id) with its own description, so the baseline is 3. The tool description does not add any additional semantic meaning to the id parameter, but none is needed since the schema alone is clear.
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 description clearly states the verb 'Obtenir' (get) and the resource 'une commande client' (a customer order), with specific detail on what is included (lignes, statut, livraisons). This distinguishes it from siblings like get_supplier_order (supplier orders) and list_orders (listing), making the purpose unambiguous.
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?
The description provides clear context: use this tool to retrieve complete details of a customer order. The word 'client' implicitly excludes supplier orders, and the detail list (lines, status, deliveries) indicates it is for full-order retrieval. However, it does not explicitly mention alternatives or when not to use it, but the scope is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a read-only listing operation through the verb 'Lister', but does not explicitly state that it is non-destructive or safe. It also does not mention any configuration nuances or potential side effects, though for a simple list tool this is a minor gap.
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?
The description is a single sentence that is concise, front-loaded with the action, and includes clarifying examples. Every word adds value, and it avoids any redundant or vague phrasing.
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 a zero-parameter list tool with no output schema, the description is complete. It clearly states that the tool returns configured payment methods and their IDs, with examples of what counts as a payment method, which is sufficient for the agent to understand the tool's function and expected result.
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?
The input schema has zero parameters, so the baseline is 4. The description does not need to explain parameters since there are none, and the schema covers 100% of the parameter surface.
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 description clearly states the tool's function: 'Lister les modes de paiement configurés' (list configured payment methods). It includes examples (Virement, Chèque, CB) and specifies the output includes IDs. This distinguishes it from siblings like list_payments, which lists actual payment transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to retrieve available payment methods and their IDs, likely for reference when creating payments. However, it does not explicitly state when to use this tool versus alternatives like list_payments or list_payment_terms, nor does it provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. 'Obtenir' clearly signals a read operation, and the parenthetical enumerates the returned data categories (lines, payments, status, amounts), providing useful behavioral detail beyond simple 'get invoice'.
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?
The description is a single, well-structured sentence in French. It is front-loaded with the action and resource, and the parenthetical adds valuable specifics without unnecessary verbosity.
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 simple get-by-ID tool with one parameter and no output schema, the description adequately explains the return contents (lines, payments, status, amounts). It could mention edge cases like not-found behavior, but this is not essential for a tool of this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single 'id' parameter, describing it as 'ID de la facture'. The tool description adds no extra parameter-specific meaning, so the baseline of 3 applies.
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 description uses the specific verb 'Obtenir' (get) with the resource 'facture' (invoice), and specifies the exact scope: 'lignes, paiements, statut, montants' (lines, payments, status, amounts). This clearly distinguishes it from list_invoices and other invoice-related 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?
The description implies the primary use case: when you need full details of a single invoice. It does not explicitly mention alternatives or exclusions, but the context is clear that this is the fetch-by-ID tool for invoices, especially given the sibling list_invoices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses the key side effect: making the quote visible and sendable. It does not mention reversibility or permissions, but the core state change is clearly stated.
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?
The description is one concise sentence with a parenthetical explaining the effect. It is front-loaded with the action and resource, with no redundant information.
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 simple two-parameter tool with no output schema, the description covers purpose and effect. It lacks details like irreversibility or permission requirements, but these are not essential for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters (id, status) described. The description adds no extra parameter detail beyond the schema, such as the status values or default behavior, so baseline 3 is appropriate.
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 description specifies the action ('Valider' - validate) and resource ('devis brouillon' - draft quote), with a clear outcome ('le rend visible et envoyable au client'). This distinguishes it from sibling tools like close_proposal or convert_proposal_to_order.
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?
The phrase 'devis brouillon' clearly scopes the tool to draft proposals, providing explicit context for when to use it. It does not explicitly mention alternatives or exclusions, but the draft scope is sufficient for basic guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It states the tool checks connection status and returns version information, implying a safe, read-only operation. While it does not explicitly mention side effects (or lack thereof), the nature of a health test is clear enough for an agent.
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?
The entire description is a single, well-structured sentence that is front-loaded with the primary action and resource. Every word adds value, and there is no wasted text or redundancy.
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 a no-parameter, read-only health check tool, the description is fully adequate. It explains what the tool does and what information it returns (connection health and version). The lack of an output schema is acceptable given the simplicity, and no additional context is necessary.
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?
The tool has zero parameters, and the schema is empty. The baseline for parameter scoring is 4, and the description correctly references the health-test and version information, which is all that is needed. No parameter documentation is required.
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 description uses a specific verb ('Vérifier') and a specific resource ('l'état de la connexion à l'API Dolibarr'), clearly distinguishing this as a health-check tool. It further clarifies with 'test de santé et informations de version', leaving no ambiguity about the tool's function relative to its many siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implicitly suggests using this tool to verify API connectivity before other operations, but no explicit when-to-use or alternative guidance is provided. With 150 sibling tools, a brief note about using this as a preliminary health check would have strengthened the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-dolibarr MCP server](https://glama.ai/mcp/servers/digitalfactorysn/mcp-dolibarr/badges/card.svg)](https://glama.ai/mcp/servers/digitalfactorysn/mcp-dolibarr)

Score Badge

Copy to your README.md:

[![mcp-dolibarr MCP server](https://glama.ai/mcp/servers/digitalfactorysn/mcp-dolibarr/badges/score.svg)](https://glama.ai/mcp/servers/digitalfactorysn/mcp-dolibarr)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/digitalfactorysn/mcp-dolibarr'

If you have feedback or need assistance with the MCP directory API, please join our Discord server