cosmo-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes. Minor overlap exists between get_sales_period and get_revenue_trend, but descriptions specify different analytical outputs. Similarly, search_items and get_item_stock are differentiated by whether a product is already identified.
Naming Consistency5/5
All tools follow a consistent verb_noun snake_case pattern with intuitive verbs (get, create, update, cancel, receive, adjust, search). No mixed conventions or vague names are present.
Tool Count2/5
With 26 tools, the server exceeds the recommended maximum of 25, making it feel heavy. Many analytics tools (get_daily_sales, get_sales_period, get_revenue_trend, get_category_performance, get_dashboard) overlap in purpose and could potentially be consolidated.
Completeness3/5
The tool set covers core inventory, sales, and supplier workflows, including image-based recognition. However, notable gaps exist: no update or delete for items (only price update), no update/delete for customers, and no cancel/update for supplier orders. Agents may face dead ends in these areas.
Average 4.1/5 across 26 of 26 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must fully disclose behavioral traits. It only says 'obtenir le résumé' (get the summary), implying a read operation, but it does not describe the return format, whether the summary is aggregated, timezone dependencies, or any side effects. This is minimal behavioral disclosure 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 brief and front-loaded with the primary action. The second sentence lists relevant usage examples, which are useful for intent matching without being redundant. It earns a high score for efficiency, though the examples could be seen as optional.
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 or annotations, so the description should fill in what the agent can expect in the response. It doesn't mention return structure, fields, or any caveats. While the tool is simple, the description leaves out important context about the output and how it differs from related period-based sales tools.
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 'date' parameter, including its ISO format and default. The description adds that the date can be a specific date, which is consistent but not additional semantic detail. 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 function with a specific verb 'Obtenir' and a resource 'résumé des ventes', and specifies the temporal scope (today or a specific date). It includes example queries to clarify intended use. However, it doesn't explicitly contrast with related tools like get_sales_period, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Utiliser pour' phrase provides clear context for when this tool should be used, listing several example user intents such as 'combien on a fait aujourd'hui' and 'CA du jour'. It lacks explicit 'when not to use' or alternative tool references, so it's a 4 rather than a 5.
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 behavior. It only says 'voir' (see), which implies a read-only operation, but does not explicitly state safety, side effects, or any limitations. There is no mention of output format or potential caveats, leaving a gap for an unannotated 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 two concise sentences, front-loaded with the core purpose, and provides usage guidance without any redundancy. Every word earns its place, 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.
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, no output schema, no annotations), and the description gives a solid overview of purpose and usage. However, since there is no output schema, the description should ideally mention what the returned data looks like (e.g., time series, chart, list) to fully prepare the agent. This is a minor gap but keeps it at minimum viable.
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 single 'days' parameter clearly with a default and French description. Schema description coverage is 100%, so the baseline is 3. The description's mention of 'N jours' aligns with the parameter but adds no additional semantic meaning beyond what the schema provides.
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 shows revenue evolution over the last N days ('Voir l'évolution du chiffre d'affaires sur les derniers N jours'). It identifies the resource (revenue trend) and the time dimension. While 'Voir' is a weak verb, the context distinguishes it from sibling tools like get_daily_sales or get_sales_period by focusing on trend evolution.
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 explicitly lists use cases: analyzing trends, identifying good/bad days, comparing weeks, and responding to user queries about 'how things are evolving'. This provides clear when-to-use guidance, though it does not mention alternatives or when-not-to-use, so it misses the top score.
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 says 'détail complet' without explicitly stating read-only nature, return structure, or side effects. The name implies retrieval but does not confirm safety or idempotency.
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 with the main action front-loaded. No unnecessary words 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?
For a simple single-parameter retrieval tool with no output schema, the description adequately covers what it does and when to use it. However, it could be more complete by describing the structure of the 'detail complet' or confirming no side effects.
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% and the parameter description already provides the invoice number format and an example (ACC-SINV-2024-00001). The description only repeats 'par son numéro', adding no new meaning beyond what the schema gives.
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 and resource: 'Récupérer le détail complet d'une facture par son numéro' (get complete invoice detail by number). This clearly distinguishes it from sibling tools like cancel_invoice or get_daily_sales.
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?
Explicit usage trigger: 'Utiliser quand l'utilisateur mentionne un numéro de facture spécifique ou veut vérifier une vente passée.' This tells when to use the tool but does not mention when-not or name alternatives directly.
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 full burden. It discloses a key behavioral trait: 'Toujours demander confirmation des informations avant de créer'. However, it does not mention permissions, side effects, or what happens after creation (e.g., whether the item is immediately available). This is useful 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 three short sentences, front-loaded with purpose, then usage triggers, then the confirmation requirement. Every sentence contributes meaningfully, with no redundancy 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 create operation with 6 parameters, the description covers the basic workflow and confirmation step. However, it does not differentiate from the sibling create_item_from_image (which may be relevant when images are involved), nor does it mention expected return values (no output schema exists). The absence of these contextual clues leaves moderate 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 description coverage is 100%, so the schema already fully documents each parameter. The description adds no additional parameter-level semantics—it only references 'les informations' generically. Baseline 3 is appropriate as 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 clearly states the tool's purpose with a specific verb and resource: 'Créer un nouveau produit dans le catalogue ERPNext'. It also provides concrete trigger phrases ('ajoute ce produit', 'nouveau produit à créer') that distinguish it from image-based creation (sibling create_item_from_image) and other item-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 gives explicit when-to-use guidance: 'Utiliser quand un nouveau produit est référencé pour la première fois' and includes user-phrase triggers. However, it does not mention when not to use it or explicitly name alternatives (e.g., create_item_from_image for image-based input), so it falls short of 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?
No annotations are provided, so the description carries the full burden. It implies a read-only analysis operation ('Analyser'), but does not disclose what metrics are included (e.g., revenue, quantity), the return format, or whether it covers all categories. 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 two sentences: the first states purpose, the second gives usage context. It is concise, front-loaded with the action, and free of 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?
The tool has one optional parameter and no output schema. The description explains purpose and use cases but does not mention what the response contains (e.g., categories with metrics) or any limitations. Given no annotations, this gap prevents a higher 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?
Schema coverage is 100% (the only parameter 'period' has an enum, default, and description). The tool description adds no parameter-specific information, so it neither compensates nor improves beyond the schema. 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 clearly states the tool's function: analyzing sales and performance by category of cosmetic products. It uses a specific verb (analyser) and resource (sales/performance by category), distinguishing it from siblings like get_sales_period or get_revenue_trend which focus on overall sales or revenue trends.
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 gives explicit use cases: determining best-selling categories, adjusting supplier orders, and optimizing shelf space. It does not name alternative tools or exclusions, but the context is clear enough for an agent to know when to select this 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?
No annotations are provided, so the description must carry the full burden. It states the core behavior (lists customers by inactivity threshold) but does not disclose the return format, ordering, or edge cases (e.g., whether customers with no purchases are included). It is not misleading 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 two sentences long, front-loaded with the action, and contains no fluff. Every sentence earns its place, providing purpose and usage context 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?
Given the low complexity (1 parameter, no output schema, no annotations), the description covers the purpose and usage but omits details about the output structure or any additional behavior. This is sufficient for a simple list tool but leaves some ambiguity for an agent expecting specific return values.
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 fully describes the only parameter 'days' with a default and explanation. The description does not add any extra parameter semantics, and 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 a specific verb ('Lister') and resource ('clients') with a clear criterion (haven't purchased for X days). It clearly distinguishes from siblings like get_top_customers (which likely focuses on top revenue) and get_customer_profile (individual customer lookup).
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 explicitly states when to use this tool: for follow-ups, loyalty campaigns, or when the user asks 'who hasn't come for a long time'. It does not mention alternative tools or when not to use it, but the context is clear.
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 is the sole source of behavioral info. It says 'obtenir' (get), implying read-only, but does not state side effects, return format, or prerequisites. However, as a simple lookup, the basic behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with a list of example phrasings. The examples are somewhat repetitive but serve as intent-matching patterns. No redundant content about unrelated features.
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 covers what, when, and preferred alternative. Missing return value format and note about at least one parameter being required, but given the tool's simplicity and schema coverage, it 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 schema fully describes item_code and item_name with priorities, and the description adds no additional parameter semantics beyond that. Descriptions of example queries imply mapping but not explicitly.
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 'Obtenir le niveau de stock actuel d'un produit spécifique' (get current stock level for a specific product), which is a specific verb+resource+scope. It also distinguishes from the alternative get_all_stock by noting preference when the product is identified.
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?
Gives explicit example queries ('combien il reste de X', 'quel est le stock de Y') and explicitly states to prefer this tool over get_all_stock when the product is known. Lacks an explicit when-not, but provides sufficient 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?
No annotations are provided, so the description carries the full burden. It explains that the tool searches ERPNext and returns a result, which implies read-only behavior, and clarifies that it does not process images itself but uses extracted data from Hermes. However, it does not disclose potential behaviors such as whether it creates records, error handling for no matches, or required permissions. The workflow transparency is useful but not fully comprehensive.
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 concise yet information-dense. It front-loads the primary purpose, then provides a numbered workflow (1-3), and ends with usage examples. Every sentence contributes value: purpose, workflow, and when-to-use. The structure is logical and easy for an agent to parse, with no 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 has no output schema, so the description should explain what the result contains. It only says 'retourne le résultat' without specifying if it includes price, stock status, or product details, despite usage examples suggesting those queries. Edge cases (e.g., no match found) are not addressed. Given the simplicity of the tool and the workflow, this is a moderate gap, making the description minimally viable but not fully 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 has 100% coverage, with descriptions for all four parameters. The description adds context by explaining that the parameters are the data extracted by Hermes from the image, which explains why they are optional and how they are used. However, it does not provide additional syntax or format details beyond what the schema already states, so a 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: identify a cosmetic product in ERPNext using data extracted from an image. It distinguishes from siblings like search_items or create_item_from_image by specifying the product identification workflow and the input of extracted data rather than raw images. The verb 'Identifier' and resource 'produit cosmétique dans ERPNext' make it specific.
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 explicit usage context: when a user sends a product photo and asks questions like 'what is this product' or 'is it in stock'. It also outlines a workflow where Hermes first analyzes the image with vision_analyze, then calls this tool, which clarifies when to use it versus performing direct image analysis. However, it does not explicitly mention alternatives or when NOT to use it beyond implicit 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains what data the profile includes but does not mention whether the operation is read-only, how missing customers are handled, or any potential side effects. This is a reasonable but not exhaustive disclosure for a simple profile lookup.
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, front-loaded with the core purpose, and uses a clear list of included data. No redundant words; every sentence adds value.
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 simple one-parameter schema and absent output schema/annotations, the description compensates by enumerating the profile fields and providing use cases. It lacks details on error conditions or data limitations, but is otherwise sufficient for a low-complexity 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?
Schema coverage is 100%, with the schema describing 'customer_name' as the exact name in ERPNext. The tool description adds no additional parameter semantics beyond what the schema already states, so it does not elevate beyond the baseline 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 the tool's function: viewing a customer's complete profile with specific included data (purchase history, favorite products, last visit, total spent). This distinctly separates it from sibling tools like get_top_customers or get_inactive_customers, which focus on customer aggregates rather than individual profile details.
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 explicit usage context: 'Utiliser pour personnaliser le service ou préparer une relance.' This tells the agent when to use the tool. However, it does not explicitly mention alternatives or when not to use it, though the sibling tool list makes those distinctions implicit.
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 describes the tool's output contents and implies a read-only aggregation via the word 'Obtenir'. However, it does not disclose behavioral details such as the default include_alerts=true behavior or whether any side effects occur. The name 'get' partially compensates, but a more explicit note about no modifications or the aggregation behavior would enhance 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 two sentences, front-loaded with the primary purpose and immediately listing key content items. It then provides concrete use cases. No filler or redundant wording; every sentence earns its place.
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 (one optional parameter, no output schema), the description is fairly complete. It explains what the summary contains and when to use it. It does not explicitly mention the include_alerts parameter, but the schema covers that, and the described contents align with the parameter's purpose. Overall, it provides sufficient context for an agent to select and invoke 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?
The schema description covers 100% of the single parameter (include_alerts), providing a clear explanation: 'Inclure les alertes stock et expiration (défaut: true)'. The tool description does not add additional parameter meaning 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.
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: 'Obtenir le résumé complet de la boutique' and lists the specific components (ventes du jour, stock critique, produits expirant bientôt, top produit du jour). This distinguishes it from sibling tools like get_low_stock_items or get_daily_sales, which cover individual aspects.
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 explicitly provides usage contexts: 'briefing matinal', 'questions générales sur l'état de la boutique', and example queries like 'comment ça se passe aujourd'hui ?'. This gives clear direction on when to use the tool, though it does not explicitly mention exclusions or alternative 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 add value by stating the default horizon ('Par défaut vérifie les 30 prochains jours') and implies future expiration, but it does not clarify whether already-expired items are excluded, how results are ordered, or any pagination/error behaviors. This is a moderate level of 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 concise and well-structured: it opens with the core function, then provides usage guidance, and closes with the default behavior. Every sentence is informative and there is no redundant content. It is appropriately sized for a simple tool.
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 (1 parameter, no output schema, no annotations), and the description covers purpose, usage, and default parameter behavior. It lacks explicit return format details, but that is not required given the simplicity. A minor gap is not mentioning whether results are sorted or if expired items are included, but overall it is complete enough for reliable 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 schema has 100% coverage for the single parameter 'days', with a default of 30. The description reinforces this by mentioning 'prochains N jours' and the default 30, but it does not add substantial new meaning beyond the schema. Since schema coverage is high, a 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: 'Lister les produits dont la date d'expiration approche dans les prochains N jours' (List products whose expiration date approaches within the next N days). This uses a specific verb and resource, and the scope is unambiguous. It also distinguishes from sibling tools like get_low_stock_items by focusing on expiration rather than stock levels.
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 explicit usage scenarios: 'Utiliser quand l'utilisateur demande les produits qui vont expirer, pour planifier des promos de déstockage, ou pour faire le point avant une commande.' These are clear contexts for when this tool is appropriate. However, it does not mention when not to use it or explicitly contrast with alternative sibling tools, so it falls short of 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?
No annotations are provided, so the description carries the full burden. It discloses return values ('Retourne CA total, top produits et répartition par catégorie') and implies read-only behavior via 'Analyser'. However, it doesn't mention edge cases, validation, timezone handling, or performance characteristics.
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, front-loaded with purpose, then usage and return values. Every sentence earns its place with no redundant fluff.
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 2-parameter tool with no output schema, the description covers purpose, usage, and return aggregates. Missing minor details like inclusive/exclusive date boundaries, but given low complexity, it is sufficiently 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%: both date_from and date_to have ISO date descriptions. The description adds no extra parameter semantics, so baseline 3 applies. It only mentions 'période personnalisée' without additional format or constraint 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 uses a specific verb+resource: 'Analyser les ventes sur une période personnalisée' clearly states the action and object. It distinguishes from siblings like get_daily_sales (fixed daily) and get_revenue_trend (trend analysis) by specifying custom period and returns (CA total, top produits, répartition par catégorie).
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?
Provides clear usage context: 'Utiliser pour les bilans semaine/mois, comparaisons de périodes, analyses de tendances.' This tells when to use the tool but does not explicitly mention alternatives or when not to use it. Context is clear enough to differentiate from sibling 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?
No annotations are provided, so the description partially compensates by disclosing the selection metric (revenue) and the time period. However, it omits details like sort order, aggregation logic, or data freshness, leaving some ambiguity.
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 plus an example, front-loaded with the core action. Every sentence earns its place 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?
Given the simple tool (2 params, no output schema), the description explains purpose, usage, and provides an example. It does not explicitly state the return format (e.g., customer names and revenue amounts), which would be helpful without an output schema, but the overall context is sufficient for most agents.
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 both parameters with clear descriptions (defaults and enum). The description adds an example ('top 10 clientes') that implicitly maps to the limit parameter, but no extra semantic depth 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 it lists the best customers by revenue over a period, using specific verbs and scope. It distinguishes itself from siblings like get_customer_profile (single customer) and get_inactive_customers (churn).
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 explicitly says to use for identifying VIPs, retention, and exclusive offers, giving clear context. It does not mention alternatives or exclusions, but the use cases are well-defined.
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?
The description adds a valuable behavioral directive by requiring confirmation before applying the change. However, with no annotations, it does not disclose other behavioral traits such as reversibility, authorization needs, or side effects on historical data.
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, front-loaded with the primary purpose, and includes actionable trigger phrases and a confirmation requirement. Every sentence earns its place with no unnecessary 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 simple price update tool with two well-described parameters, the description covers when to use, what it does, and the confirmation step. However, it lacks information about return values or error handling, which could be relevant given the absence of an 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?
Both parameters are fully described in the schema (item_code and new_price in Ariary). The tool description adds no additional parameter semantics beyond what the schema already provides, 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 action: updating a product's selling price. It provides specific trigger phrases and distinguishes this tool from stock-related siblings like adjust_stock.
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?
Explicit usage criteria are given with trigger phrases, and the confirmation step is a clear behavioral instruction. However, it does not mention when not to use this tool or suggest alternative tools, so it lacks exclusions or alternatives.
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 tool adds to the catalog and uses extracted data, but does not mention side effects such as duplicate handling, permission requirements, or failure modes. This is adequate but not comprehensive.
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 purpose front-loaded and usage context following. No redundancy, every word earns its place.
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?
Provides clear workflow context (after identify, when not found, user confirmation) and input expectations. Lacks return value and error behavior details, but given the simple creation action and no output schema, it is reasonably complete 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 80%, so most parameters are already documented. The description only adds the context that parameters come from image extraction, but does not elaborate on syntax or meaning beyond the schema. 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 it creates a product sheet from photo-extracted data, and explicitly positions it after identify_product_from_image for unreferenced products. This distinguishes it from the generic create_item sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use after identify_product_from_image when the product is not found in ERPNext and the user confirms adding it. This gives clear triggers and preconditions, eliminating ambiguity about when to invoke.
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?
Since no annotations are provided, the description carries the full burden. It emphasizes a critical safety behavior: presenting a summary and asking for confirmation before creating the sale, with a specific confirmation format. It does not mention other behaviors like permissions or return values, but the confirmation step is a key transparency element beyond the 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 concise and well-structured. It front-loads the purpose, gives usage triggers, and then the IMPORTANT confirmation instruction. Every sentence earns its place, and the formatting with uppercase 'IMPORTANT' draws attention to the critical behavior without 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?
Given the tool's complexity (4 parameters, no output schema, no annotations), the description provides essential context: the purpose, trigger phrases, and the mandatory confirmation step. It does not explain return values or side effects like stock updates, but for a creation tool, key user-facing behavior is covered. This is more than adequate but not fully exhaustive.
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 does not add parameter-specific details beyond the schema; it only implies calculating a total during confirmation. It does not duplicate or contradict the schema, but also does not provide extra value for understanding the 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 states a specific verb and resource: 'Créer une vente / facture client dans ERPNext' (create a sale/customer invoice). It clearly distinguishes this from sibling tools like get_daily_sales or get_invoice, which are read-only. The trigger phrases further clarify the intent.
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 explicitly lists when to use the tool with example user phrases ('vendre X à Y', 'créer une facture pour', etc.). It gives clear usage context, though it does not mention when not to use it or any alternatives. This fits 'clear context, no exclusions'.
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 provided, so the description carries full transparency. It discloses the mutating action (create) and goes beyond that by detailing required behavior: check current stock, present a full summary, and request confirmation. This adds valuable context, though it does not cover permissions, reversibility, or post-creation 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?
Three sentences, each earning its place: the action, the usage trigger, and the essential pre-flight checks. No redundancy, well front-loaded with the main purpose.
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 creation tool with no output schema and no annotations, the description provides the core action, when to use, and critical workflow steps (check stock, confirm). It omits the return value or system effects, but the essential guidance is solid and sufficient 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 100%, with each parameter already well-described (e.g., supplier_name as 'Nom exact du fournisseur dans ERPNext', rate as 'Prix d'achat optionnel'). The description adds no parameter-level detail beyond the schema, 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 clearly states 'Créer une commande fournisseur dans ERPNext' (create a supplier order) and further explains it is for ordering products from a supplier. This specific verb+resource combination, along with the supplier context, distinguishes it from siblings like create_sale or receive_stock.
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 explicitly says to use when the user wants to order products from a supplier, and provides a mandatory pre-check ('Toujours vérifier le stock actuel') and confirmation step. While it does not mention when not to use or name alternatives, the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 reveals the operation is a read-only listing by using 'Lister', which implies no side effects, but it does not disclose additional behavioral traits such as sort order, inclusion of zero-stock vs. negative-stock, or handling of items without a minimum threshold. The description is minimally sufficient 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 two sentences: the first defines the function, the second provides usage scenarios. Every sentence adds value with no redundancy or filler.
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 zero-parameter list tool, the description covers the core purpose and common user intents. It lacks explicit return format or pagination details, but the absence of an output schema and the simplicity of the operation make this a minor gap; the use-case list adds practical 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 tool has zero parameters and the input schema is empty, so schema coverage is 100%. The description adds no parameter-specific information because there is nothing to document; baseline of 4 for zero-param tools 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 produits dont le stock est sous le seuil minimum de réapprovisionnement'), and it distinguishes itself from siblings like get_item_stock and get_expiring_items by defining a unique scope (items below reorder threshold).
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 explicitly states when to use the tool: 'Utiliser pour les alertes de réapprovisionnement, les rapports du matin, ou quand l'utilisateur demande...' and provides concrete example queries. It doesn't list exclusions or alternatives, but the when-to-use context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 order state (sent but not received) but does not mention response format, pagination, or side effects. For a simple read tool, this is adequate but minimal.
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 sentences, front-loaded with the main action, then usage triggers. No wasted words; every sentence earns its place.
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 zero parameters and no output schema, the description is sufficient: it explains what the tool does and when to use it. It could mention the return format, but for a simple list, it is reasonably complete.
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 coverage is 100% (empty schema). The description needs to explain no parameters, so the baseline of 4 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 ('Voir') and resource ('commandes fournisseurs en cours'), and clarifies scope with 'envoyées mais pas encore reçues', distinguishing it from other supplier-order tools. It is immediately clear 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage contexts: 'suivi des livraisons' and specific user phrasings ('les commandes en attente', 'qu'est-ce qu'on attend comme livraison'). It lacks explicit when-not-to-use or alternatives, but the guidance is clear for a simple read-only 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 full burden. It notes that only 'actifs' (active) suppliers are returned, which is a behavioral filter. However, it does not disclose other traits such as whether the operation is read-only (though 'lister' implies it), potential pagination, or any side effects. The description is not misleading, but it lacks additional 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 two concise sentences. The first states the action, the second states when to use it. Every word adds value, with no redundancy or irrelevant 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 zero-parameter list tool, the description provides the core purpose and usage context. It mentions the output includes suppliers and their usual products, which gives some return-value information. Since there is no output schema, this is sufficient for most practical scenarios, though it could be slightly more explicit about the data 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 zero parameters and the schema coverage is 100% (empty property set). According to the rubric, 0 parameters warrants a baseline of 4 since there is no parameter information to add. The description focuses on the output, which 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 specific verb 'Lister' (list) and names the resource 'fournisseurs actifs' (active suppliers), making it clear this returns a list of active suppliers. It adds 'avec leurs produits habituels' (with their usual products), which distinguishes it from sibling tools like get_item_stock or get_low_stock_items.
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 explicitly states when to use the tool: 'Utiliser pour savoir auprès de qui commander un produit, ou avant de créer une commande fournisseur' (Use to know from whom to order a product, or before creating a supplier order). It provides clear use cases but does not mention when not to use it or alternative tools.
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?
La description révèle le comportement de sortie : 'Retourne le prix et le stock de chaque résultat', ce qui est utile car aucune annotation n'est fournie. Elle ne mentionne pas la pagination ou les autorisations, mais pour un outil de recherche en lecture seule, cela suffit.
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?
La description tient en trois phrases, chacune ayant un rôle distinct : objet et critères de recherche, cas d'utilisation, et résultat renvoyé. Aucun mot superflu, la structure est front-loadée avec l'action principale.
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?
L'outil est simple : le schéma décrit les deux paramètres, et la description explique ce que renvoie l'outil. Il manque une mention explicite du filtre par catégorie, mais il est dans le schéma, donc l'ensemble est suffisant.
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?
La couverture du schéma est de 100% : les deux paramètres (query et category) ont des descriptions. La mention 'par nom, code ou marque' dans la description répète simplement la description du paramètre query sans ajouter de valeur supplémentaire par rapport au 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 commence par 'Rechercher des produits dans le catalogue', ce qui indique clairement l'action (recherche) et la ressource (produits). Elle précise les critères de recherche (nom, code, marque) et se distingue de ses outils frères comme get_item_stock ou get_low_stock_items, qui sont des recherches ciblées de stock.
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?
La description fournit des cas d'utilisation explicites : 'pour trouver un produit avant une vente, avant une commande fournisseur, ou pour vérifier si un produit existe dans le système'. Elle ne mentionne pas explicitement quand ne pas l'utiliser ni d'outils alternatifs, mais le contexte d'utilisation est clair.
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 provided, so the description carries the full burden of behavioral disclosure. It clearly states that the tool creates a Cosmo OCR Invoice and proposes a Purchase Invoice, which are significant side effects. It also implies a data transformation step (from image analysis to structured data). However, it does not mention potential reversibility, error handling, or whether it modifies existing records, which could be important 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 concise but information-dense. It front-loads the purpose, then provides a numbered workflow that is easy to follow. Every sentence adds value, including the when-to-use line. No fluff or repetition. The length is justified by the workflow explanation.
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 complexity (6 parameters, 3 required, no output schema), the description is fairly complete: it explains the workflow, the preconditions (Hermes vision_analyze), and the expected outcomes (Cosmo OCR Invoice, Purchase Invoice). It does not describe the return value or post-creation steps, but for an internal workflow tool, this is a minor gap. The absence of an output schema raises the bar, but the description covers the 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?
Schema description coverage is 100%, and each parameter has a clear French description (e.g., 'Lignes de produits extraites', 'Montant total de la facture'). The description adds context that these parameters come from Hermes's extraction, but it does not elaborate on specific formats, constraints, or relationships beyond what the schema already provides. Baseline 3 is appropriate since the schema handles 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 purpose: recording a supplier invoice extracted from an image by Hermes. It specifies the exact action (enregistrer une facture fournisseur), the resource (facture fournisseur), and the workflow (creating a Cosmo OCR Invoice and proposing a Purchase Invoice). This distinguishes it from sibling tools like create_item_from_image or identify_product_from_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Utiliser quand l'utilisateur envoie une photo de facture fournisseur.' It also outlines a three-step workflow, making it clear that this tool is called only after Hermes has analyzed the image with vision_analyze and extracted structured data. This implicitly excludes using it for other invoice types or without prior image analysis.
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. It discloses the underlying operation (creates a Stock Entry of type Material Receipt in ERPNext), which is a key behavioral trait. It also warns against misuse for inventory corrections. However, it does not mention side effects like stock level changes or return values, which would add completeness.
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 concise and well-structured: it starts with the purpose, then usage triggers, then implementation detail, and ends with an important exclusion. Every sentence adds value, with no 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 moderate complexity, the description gives clear context for intent, usage, and underlying ERPNext operation. The main gap is the lack of return value information (since there is no output schema), but the overall context is sufficient for an agent to select and invoke 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?
The schema covers 100% of parameters with descriptions, so the baseline is 3. The description does not add extra parameter-level detail beyond the schema. It indirectly references 'fournisseur' and 'unités' but does not provide additional 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 'Enregistrer une réception de marchandise fournisseur dans le stock' (record a supplier merchandise receipt in stock), specifying both the action and the resource. It further clarifies it creates a Stock Entry of type Material Receipt in ERPNext, distinguishing it from sibling tools like adjust_stock.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use triggers ('on vient de recevoir X unités de Y', 'livraison reçue de [fournisseur]', 'entrée stock', 'on a reçu la commande') and an explicit when-not-to-use exclusion with a named alternative: 'ne pas utiliser pour des corrections d'inventaire, utiliser adjust_stock.'
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?
Since no annotations are provided, the description carries the full burden. It discloses that the action is irreversible and requires user confirmation, which is valuable for a mutation tool. However, it doesn't mention what happens on execution (e.g., whether it logs the change or affects other records), but the context of stock correction is well conveyed.
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, front-loaded with the verb and resource, and includes essential usage exclusions and safety warnings. Every word earns its place, no 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?
Despite having no output schema, the description covers the tool's purpose, specific use cases, exclusions, alternative tool, and safety requirement. It is sufficiently complete for a stock-adjustment tool with three well-documented 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%, with each parameter (item_code, new_qty, reason) having a clear description. The tool description adds no extra parameter semantics beyond what the schema already provides, 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 purpose: 'Corriger le niveau de stock' (correct the stock level) for specific scenarios (inventory, loss). It distinguishes itself from receive_stock, making the purpose unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (corrections for physical inventory, breakage, theft) and when not to (supplier receipts), naming the alternative tool receive_stock. Also instructs to ask for user confirmation, providing clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the critical IRREVERSIBLE nature of the action and mandates user confirmation before execution, providing essential behavioral context 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 four short, direct sentences in French, front-loaded with the purpose and immediately followed by critical warnings. Every sentence adds value 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?
The tool has no annotations and no output schema. The description covers purpose, irreversibility, confirmation, and usage condition, which is comprehensive. However, it could specify the invoice's post-cancellation state or side effects, though this is minor given the clarity already provided.
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 both parameters are fully documented. The description reinforces that the invoice number and reason are needed ('avec le numéro de facture et le motif') but adds no new semantic information 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 clearly states the tool's function: 'Annuler une facture existante' (cancel an existing invoice). This specific verb+resource combination distinguishes it from sibling tools like get_invoice. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Utiliser uniquement en cas d'erreur avérée' (use only in cases of proven error) and 'Ne jamais annuler sans confirmation explicite de l'utilisateur' (never cancel without explicit user confirmation). This clearly indicates when and when-not to invoke the tool.
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 provided, the description carries the full burden. It discloses the search order (name then phone), that it proposes creation, and implies auto-creation is controlled by the create_if_not_found parameter. However, it does not specify behavior for edge cases like multiple matches or when creation is declined.
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 concise (three sentences), front-loaded with the core purpose, and includes a practical example. Every sentence earns its place with no fluff.
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 covers purpose, usage trigger, search strategy, and an example, which is fairly complete for a find-or-create tool. However, it lacks details on what happens when the customer is not found and create_if_not_found is false or how the result is returned, especially since there is no output schema. Still, the core behavior is well explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by specifying that name and mobile_no are used in a particular search order (name first, then phone), which enriches the semantic meaning beyond the schema's simple 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 finds an existing customer or creates a new one, with a specific verb and resource. It also distinguishes this tool by providing usage context with create_sale, making its 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use before create_sale when the user mentions a customer name, and provides a clear search strategy (by name then phone) before proposing creation. This gives concrete when-to-use guidance and differentiates from alternatives.
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:

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

Score Badge

Copy to your README.md:

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

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/jonathanARMS23/cosmo-mcp'

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