waro-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Several tools have overlapping analytics purposes (analytics_waros, analytics_rfm, analytics_churn_risk, analytics_food_cost, analytics_alerts, analytics_data_quality, analytics_cohort, analytics_menu) but each targets distinct metrics. Some confusion possible between waros_estimate and waros_balances/customer, and between sales_list/metrics/detail and customers_orders, but descriptions are specific enough. However, sales_list vs sales_detail are clear, and customers_orders vs customers_list/detail are distinct. The overlap in analytics tools is moderate, but not severe.
Naming Consistency3/5
The naming follows a general pattern of domain_subject, e.g., 'analytics_*', 'waros_*', 'queries_*', 'sales_*', 'customers_*', 'menu_*'. This is fairly consistent, but there are some deviations: 'waro_schema' and 'waro_ping' use a different prefix than the 'waros_*' group, and mixed order in 'financial_products'. The pattern is mostly predictable but has minor irregularities.
Tool Count4/5
26 tools is slightly heavy but within the range for a comprehensive business analytics server covering multiple domains (analytics, sales, customers, menu, WAROS, queries). The count is high but each tool appears purpose-specific and covers a broad domain, so it's acceptable. Not excessive like 50+.
Completeness4/5
The tool surface covers a wide range of business analytics: sales, customers, menu, WAROS, financial metrics, queries. It includes list/detail/metrics and analytics for major areas. However, there are some gaps: no tool for updating/creating data (though analytics servers are often read-only), no explicit tool for user management or settings, but for the intended purpose of analytics and reporting, it seems fairly complete. There is also a queries_run and queries_schema for custom queries, which adds flexibility.
Average 2.4/5 across 26 of 26 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry all behavioral transparency, but it provides none. It does not mention side effects, permissions, return types, or any side effects, making it impossible to understand what the tool does beyond a generic label.
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, which is concise, but it sacrifices clarity. It lacks any structural elements like verb-first phrasing or scoping, making it ineffective despite its 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?
The tool is severely incomplete: no parameter descriptions, no output schema, and no mention of expected results. The description does not provide enough context 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'fields' is a string with no description in the schema, and the tool description does not explain its purpose. There is zero semantic information about what fields are expected or how they influence the tool's behavior.
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 'Alertas analiticas y recomendaciones' is vague and does not specify a clear action or resource. It fails to distinguish this tool from siblings like analytics_waros or analytics_cohort, providing only a broad notion of alerts and recommendations.
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 given on when to use this tool versus alternatives. The description lacks any conditional statements, use cases, or exclusions, leaving the agent without direction for 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 provided, the description carries the full burden of behavioral disclosure, but it only states that this tool produces alerts. It does not explain whether it's read-only, what triggers the alerts, how data is returned, or any side effects. The behavior is effectively opaque.
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. While there is no wasted verbiage, it lacks enough content to be useful, making it not appropriately sized for the information an agent needs.
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?
Despite having only one parameter and no output schema, the description is far from complete. An agent cannot infer what the tool returns, how to interpret the alert data, or what 'fields' should contain. Even basic expectations are missing.
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 only parameter 'fields' is described only as a string with no schema description (coverage 0%). The tool description doesn't explain what 'fields' refers to or what values are expected. 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Alertas calidad de datos en compras e ingredientes' identifies a resource (data quality alerts in purchasing and ingredients) but uses a noun phrase rather than a specific verb. It conveys a vague purpose, not a clear action, and doesn't differentiate from sibling tools like analytics_alerts.
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?
The description provides no guidance on when to use this tool versus alternatives. No exclusions, prerequisites, or comparative context with sibling tools are given. An agent has no way to decide between this and analytics_alerts.
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 behavior. It does not state whether the tool is read-only, what it returns, whether it has side effects, or any other behavioral trait. The phrase only names the topic, so an agent cannot infer operation semantics.
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 conciseness. It lacks a verb and reads as a fragment, so it is not a well-structured tool description. Every word is potentially useful but the absence of an action makes it ineffective.
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 output schema, no annotations, and 3 undocumented parameters, the description should explain the return value, the meaning of the parameters, and the expected behavior. It offers none of this, so an agent cannot 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 schema has 0% description coverage, so the description must compensate by explaining parameter meaning. It provides none of this: limit, fields, and offset are not mentioned or connected to the tool's behavior, leaving the agent without any context for these parameters.
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 'Grupos de modificadores y productos asociados' is a noun phrase identifying the resource (modifier groups and associated products) but lacks any verb indicating the action (e.g., list, get, create). It provides some subject matter context but does not clearly state what the tool does, making it hard to distinguish from a generic query or mutation 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?
No guidance is given on when to use this tool versus siblings like menu_products or menu_recipes. The description does not mention alternatives, use cases, or conditions that would help an agent select this tool appropriately.
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. It does not disclose whether this is a read or write operation, what side effects exist, pagination behavior, or any constraints. The phrase 'active recipes and ingredients' suggests a read operation, but nothing is explicit. The description is purely a noun phrase with no behavioral information.
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 (three words) but this is under-specification, not conciseness. It offers no useful information and fails to earn its place. A concise description that conveys meaning would be acceptable; this one conveys almost nothing.
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?
This is a data-returning tool with 3 parameters, no output schema, and no annotations. The description provides none of the pagination context (limit/offset), field selection (fields), or behavior of what 'active recipes and ingredients' means. An agent cannot reasonably determine what this tool returns or how to call it 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 parameter names (limit, fields, offset) are generic pagination/selection fields, but the description provides zero explanation of them. The description doesn't mention parameters at all, so an agent has no idea what 'fields' accepts or how 'limit' and 'offset' behave. With no schema descriptions, the tool description must compensate and 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 'Recetas activas e ingredientes' is a noun phrase stating the resource (recipes and ingredients) but lacks a verb – it doesn't say whether the tool lists, creates, updates, or deletes them. It also doesn't clarify what 'active' means. This is more than a tautology but far from a specific verb+resource statement, and it doesn't help distinguish from siblings like menu_products or menu_modifiers.
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 indication of when to use this tool versus alternatives. No mention of context, exclusions, or related tools. An agent would have to guess when to call this vs menu_products or analytics_menu. The only hint is the name itself, which is not 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 does not indicate whether the operation is read-only, what data it returns, how it is aggregated, how date filters affect results, or any other runtime behavior.
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, which is not true conciseness but under-specification. With three parameters and no annotations, a four-word phrase does not earn its place as a sufficient explanation.
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 absent annotations, no output schema, and 0% parameter documentation, the description is completely inadequate. An agent cannot reliably determine what to pass, what to expect back, or how this tool differs from sibling analytics 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?
Schema description coverage is 0%, and the description does not compensate. It never explains what 'fields' controls, or what formats or semantics 'date_from' and 'date_to' expect. The phrase 'por producto' gives a hint about output granularity but nothing about the parameters.
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 identifies the domain and granularity ('food cost y margen por producto' = food cost and margin per product), which lets an agent know it is about per-product food cost. However, it lacks a verb, so it does not state whether the tool calculates, lists, or exports these figures, and it does not distinguish itself from sibling analytics or financial 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?
There is no guidance about when to use this tool versus alternatives such as analytics_waros, financial_products, or menu_products. The description merely names the topic; it provides no conditions, exclusions, or 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?
With no annotations provided, the description carries the full burden of disclosing behavior. It only names the segmentation concept and does not state whether the tool computes a report, writes data, requires authentication, or has side effects. This is a significant gap for a tool with no structured behavioral hints.
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 short and contains no filler, which is efficient. However, it is under-specified for a tool with parameters and no schema descriptions, so the brevity reads more as incompleteness than as well-structured 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 tool with three unannotated parameters, no output schema, and no sibling differentiation, the description is not complete enough to guide correct invocation. It provides the high-level topic but omits parameter semantics, expected output, and usage 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 description coverage is 0%, and the description mentions none of the three parameters: fields, date_to, or date_from. There is no guidance on how to express date ranges or what 'fields' should contain, so an agent cannot reliably fill in the parameters from this description.
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 identifies the tool's subject as RFM segmentation by recency, frequency, and value, which makes the basic intent clear. However, it is a noun phrase rather than a concrete action statement, and it does not distinguish this tool from sibling analytics tools such as analytics_cohort or analytics_churn_risk.
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 about when to use this tool instead of the many other analytics tools. The only implied usage is 'when you need RFM segmentation,' which is not enough to choose between this and related analytics siblings.
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. 'Analisis financiero' implies a read or compute operation, but the description does not disclose whether date parameters are required, how aggregation works, side effects, or what the response contains.
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 contains no fluff, but it is a fragment with no structural guidance. It is under-specified rather than deliberately 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?
With no annotations, no output schema, and no parameter descriptions, an agent cannot reliably determine what input to provide or what the tool returns. The description is too sparse for a 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.
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 explain fields, date_from, or date_to. The mention of margin/cost/profit does not map explicitly to any parameter.
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 identifies the resource (financial products) and metrics (margin, cost, profit), but it is a noun phrase without a verb. It does not distinguish this tool from siblings like menu_products or analytics_menu.
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. With many sibling analytics and product tools, the description does not state selection criteria, exclusions, or preferred contexts.
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 does not state whether the operation is read-only, what it returns, any side effects, or limitations. The phrase 'clientes en riesgo churn' gives no 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, a single short sentence, which is good for front-loading. However, conciseness is not a virtue when critical details are omitted. It earns credit for brevity but suffers from incomplete 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?
Given only two optional parameters and no output schema, the description is inadequate. It does not define what 'silencio' means operationally, what the return format is, or any usage constraints. An agent cannot confidently determine how to call this tool or interpret results from the description alone.
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%, so the description must compensate. It does not explain what 'limit' or 'fields' mean in context, nor how they affect results. The schema itself provides constraints (default 20, max 100) but not semantics. The description adds nothing about 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 'Clientes en riesgo churn por silencio' clearly identifies the subject (customers at risk of churn due to silence) and the context. It distinguishes from siblings like analytics_rfm by focusing on churn risk from inactivity. However, it lacks an explicit verb (e.g., 'list', 'calculate'), relying on the tool name. Still clear enough.
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 analytics_rfm, analytics_cohort, or others. There is no mention of prerequisites, typical scenarios, or when this would be preferable. Agents must infer usage solely from the name and brief phrase.
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 doesn't disclose whether the tool is read-only, whether it has performance implications, whether it requires authentication, what the response looks like, or any side effects (e.g., dry_run parameter suggests possibly a preview mode but this isn't explained). The description is minimal and doesn't cover any behavioral aspects.
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 with no waste, but it's under-specified. It provides a decent amount of information per word, but the brevity itself is a problem because it leaves out critical context. It's concise but not necessarily well-structured for aiding understanding.
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 7 parameters, no schema descriptions, no output schema, and no annotations, the description is severely incomplete. It doesn't explain the purpose of the tool beyond a vague phrase, doesn't clarify required vs optional parameters, doesn't mention the return format, and doesn't address any caveats. An agent would struggle to call this tool correctly without additional information.
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 0%, meaning the schema provides no descriptions for the 7 parameters. The description mentions 'por periodo' (by period) which hints at date_from/date_to, but doesn't explain any of the other parameters: limit, fields, offset, dry_run. The description adds minimal meaning over the raw parameter names, which are self-explanatory to some extent (limit, offset, date_from, date_to) but fields and dry_run are ambiguous. Baseline for 0% coverage is low, and this description doesn't 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 is a single phrase 'Ordenes de un cliente por periodo' meaning 'Orders of a customer by period' in Spanish. It states a verb-resource relationship but lacks specificity about what operation is performed (list, retrieve, aggregate). It doesn't explain the meaning of the date range parameters or the other input fields. The name 'customers_orders' is similar to other siblings like 'customers_list', 'customers_detail', but the description doesn't distinguish it clearly.
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 vs alternatives. The sibling list includes many analytics and customer tools, but there's no exclusions or context. An agent has to infer from the name and short description that it's about customer orders by period, but no direction is given about which use case it fits or how it differs from e.g. 'customers_detail' or 'analytics_*' 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 shoulders the full disclosure burden but reveals almost nothing behavioral: 'Resumen' (summary) weakly implies a read-only aggregate operation, but the tool never clarifies what happens on invoke, whether authentication is required, what WAROS data means, or the output shape. Barely better than a tautology, and the read-only implication is the only positive signal.
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?
Brevity without substance is under-specification, not efficiency. Like the 'Process' calibration example, this fragment is short because it stops at labeling the tool rather than adding value, so there is no front-loaded insight an agent couldn't derive from the tool name alone.
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 2-parameter tool with no annotations and no output schema, the description leaves critical gaps: no definition of WAROS, no return-value description, no guidance on the 'fields' parameter, and no differentiation from 26 siblings. The missing output schema and annotations make the terse description even more costly—an agent does not have enough to call this 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?
Schema description coverage is 0%, so the burden falls on the description, which provides only marginal help: 'de un cliente' suggests profile_id identifies the customer, but the optional 'fields' parameter is entirely unexplained (comma-separated? array encoded as string?) and its effect on the response is a mystery. The description fails to compensate for the empty schema documentation.
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 six-word Spanish description 'Resumen WAROS de un cliente' (WAROS summary of a customer) names a specific resource and scope, letting an agent infer this returns a customer's WAROS summary. However, 'WAROS' is unexplained jargon, the phrase is a verbless noun fragment, and it doesn't differentiate from siblings analytics_waros, waros_estimate, and waros_balances, all of which touch the same concept.
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 whatsoever on when to use this tool versus the three other 'waros'-named siblings or analytics_waros. Unlike the get_calls example, which routes agents to its alternative ('use search_calls_extensive instead'), this description provides no context for selecting between closely 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?
The description discloses the output type (matrix) and granularity (weekly/monthly), but nothing about how date_from and date_to affect the cohort, what the matrix rows/columns represent, or any data freshness or calculation behavior. With no annotations, the description carries the full burden and 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is compact and has no filler, so it earns credit for front-loading the core concept. However, it is not appropriately sized for a three-parameter tool because it omits essential semantic and usage context; this is underspecification rather than elegant concision.
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 explain the shape of the returned cohort matrix, the role of the date parameters, and how this relates to the sibling analytics tools. It only states 'weekly/monthly retention cohorts matrix', leaving the agent to infer almost all call-relevant behavior.
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 only mirrors the period enum by saying weekly/monthly. It provides no meaning for date_from or date_to, no format guidance, no mention that parameters are optional, and no explanation of how they bound the cohort matrix.
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 producing a weekly/monthly retention cohort matrix, which conveys a clear resource and output focus. It is not a verb+resource construction, but 'Matriz cohortes retencion semanal/mensual' is specific enough to be distinguished from sibling analytics tools like analytics_rfm or analytics_churn_risk.
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 about when to choose this tool over the many analytics siblings, nor does it mention how the date parameters should be used or that all parameters are optional. It only implies that this is for retention cohort analysis, which is too weak for a clear usage rule.
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 needed to carry the full behavioral burden, but it only names metrics. It does not state whether the tool computes and returns data, whether it is read-only, what grouping does, or what the response looks like. 'Analitica' implies analysis but does not make the behavior explicit.
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 is a fragment without a sentence structure that front-loads a callable action or key usage constraint.
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, no output schema, and no parameter descriptions, this description is too sparse to be complete. It identifies the metric areas but omits date-range behavior, grouping options, response format, and how this differs from sibling 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?
Schema description coverage is 0%, and the description says nothing about date_from, date_to, or group_by. The enum values for group_by are visible in the schema, but the description contributes no parameter meaning or usage hints, leaving the agent to guess date formats and grouping 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 identifies a specific analytical domain (WAROS) and enumerates the report contents (issued, redeemed, rate), making its purpose reasonably clear. It lacks an explicit verb like 'get' or 'list', but the resource and metric set are concrete enough to distinguish it from related waros tools such as waros_balances or waros_estimate.
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 about when to choose this tool over alternative analytics/waros tools. There is no mention of prerequisites, exclusions, or conditions, so the agent must infer usage solely from the tool name and the metric labels.
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 behavioral burden. It only says that a summary is produced, without explaining date-range semantics, aggregation logic, consuming behaviors, dry-run behavior, or return characteristics.
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 contains no filler, which is efficient, but it is more of a label than a properly structured tool description. It sacrifices necessary detail 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?
For a 4-parameter tool with no output schema and no annotations, the description is under-built. It states high-level content but does not cover date handling, fields, dry_run, output shape, or meaningful nuances needed for a correct 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 adds no meaning for fields, date_from, date_to, or dry_run. An agent cannot infer how to set the parameters correctly from this 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 clearly states the resource (customers) and the kind of result: a summary of new vs returning customers and top customers. It does not explicitly distinguish itself from sibling tools like customers_orders or analytics_rfm, so it misses the top score.
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 about when to use this tool instead of related siblings such as customers_list, sales_metrics, or analytics_rfm. No conditions, hints, or alternative tool selection advice 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 were provided, so the description carries the full burden of conveying behavior. 'Estimacion WAROS por compra' gives no hint about side effects, whether the tool is read-only, authentication needs, or what side effects occur. It doesn't contradict any annotations because there are none, but it offers essentially no behavioral disclosure for what appears to be a calculation-like 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 three words long with no filler, front-loading the core phrase 'Estimacion WAROS' and appending the scope. It's an efficient use of space given there's almost nothing to it. However, it's so terse that it borders on under-specification rather than careful 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?
With only two parameters and no output schema or annotations, the description should be able to fully specify the tool's use, but it leaves out the return behavior, whether the operation is persistent, and what 'estimate' means. For a low-complexity tool like this, the description is inadequate to allow correct invocation without 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?
Schema description coverage is 50% (total is described, customer_id is not), but the tool description adds zero parameter information. Even though the total field has a description, the description here doesn't confirm the meaning of 'WAROS' (e.g., tax, discount) or clarify what customer_id represents. The description misses a clear opportunity to compensate for the undocumented parameter.
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 'Estimacion WAROS por compra' is a noun phrase that roughly translates to 'WAROS estimate per purchase,' which conveys the domain and per-transaction scope without a clear action verb. It's a step above a pure tautology because 'por compra' narrows it to a purchase context, but an agent can't tell if this reads, creates, or calculates anything. It does not differentiate from siblings like waros_balances or waros_customer, which could also relate to purchases.
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 any alternative. The description does not reference sibling tools, define prerequisites, or state what kind of inputs trigger this operation. An agent would have no way to decide between waros_estimate and waros_customer for a purchase-related task.
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 implies a reporting or read-only operation but never states whether calling this tool has side effects, requires specific permissions, or aggregates/precomputes data. At best, it describes content, not behavior.
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 in one short phrase with no redundancy and is easily scanned. However, its brevity makes it a fragment rather than a self-contained functional description, so judged as an effective structure it feels 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?
With no annotations, no output schema, and zero parameter coverage, the description leaves important invocation details unresolved. The parameter names are somewhat self-explanatory, but the lack of expected values, defaults, or response shape means an agent would still have to guess or experiment to use the tool 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 schema has three string properties with zero documentation, and the description does not explain the fields, date_from, or date_to parameters explicitly. The listed metrics hint at the domain and possible field values, but they do not define allowed values, formats, or optionality beyond the schema's bare types.
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 a product-level menu performance report and names the concrete metrics included: unidades, ingresos, margen. It is a noun phrase rather than a verbed action, but it sufficiently signals the tool's content and sets it apart from customer or financial analytical siblings like analytics_rfm or analytics_food_cost.
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 about when to prefer this tool over other analytics or menu tools, nor does it mention any required context such as date ranges or filtering. There are no exclusionary notes or alternative tool references, leaving usage entirely to inference.
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 it lists customers, without explaining pagination behavior, date filtering semantics, the 'all' flag, dry_run behavior, or how WAROS balances are computed. The word 'Lista' implies a read operation, 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 sentence with no filler, and every word adds some information. It is concise and easy to parse, though the brevity leaves important operational details unstated.
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 7 parameters, no annotations, no output schema, and no schema-level parameter descriptions, a one-line purpose statement is insufficient. The description omits filter semantics, dry_run behavior, pagination, field selection, and how this tool relates to sibling customer/metrics 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 input schema has 7 parameters with 0% description coverage, and the description does not explain any of them. Terms like 'frecuencia', 'valor', 'ticket', and 'saldo WAROS' describe output fields, not parameter meaning. The agent receives no help understanding all, limit, offset, fields, date_from, date_to, or dry_run.
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 verb ('Lista') and resource ('clientes') and specifies the returned attributes: frequency, value, ticket, and WAROS balance. This makes the core purpose understandable, though it does not explicitly distinguish itself from sibling tools like customers_metrics or waros_customer.
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 customers_metrics, customers_detail, or waros_balances. No prerequisites, exclusions, or selection conditions are mentioned, leaving the agent to infer usage 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals the data scope but says nothing about pagination, dry_run semantics, read-only behavior, or response 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 single sentence with no filler and is front-loaded with the resource name. It is concise, though the terseness comes at the cost of useful guidance.
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 four parameters, no output schema, and no annotations, this description is too thin. It covers the general purpose but leaves parameter usage and behavioral details undocumented.
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 limit, offset, fields, or dry_run. An agent cannot infer parameter meaning from either the schema or 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 clearly identifies a product catalog resource and lists the content areas: products, prices, costs, recipes, and availability. It does not explicitly differentiate from siblings like menu_recipes or analytics_menu, 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?
There is no guidance on when to use this tool versus alternatives such as menu_recipes, menu_modifiers, or analytics_menu. No exclusions, prerequisites, or alternative routing 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, the description must disclose behavioral traits. It only mentions 'lists' without stating it is a read-only operation, any authentication requirements, or what the response contains. The minimal wording provides no added 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 a single, clear sentence with no filler. It is appropriately concise, though its brevity leaves out critical 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?
Given the lack of annotations, output schema, and parameter explanation, the description is insufficient for an agent to reliably call the tool. It fails to clarify what 'QuerySpec' refers to, what the return format is, or how the 'fields' parameter influences results.
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 sole parameter 'fields' has zero schema description coverage, and the tool description does not explain its purpose or possible values. An agent has no way to understand how to use or format this 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 tool lists datasets, dimensions, measures, and QuerySpec filters, identifying a specific verb and resource. However, it does not differentiate itself from the sibling 'waro_schema' or clarify the output format, leaving some 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?
No guidance is provided on when to use this tool versus alternatives like 'waro_schema' or 'queries_run'. The description gives no context for selection, leaving an agent to guess.
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 does not disclose any behavioral aspects such as read-only nature, permissions, response format, or side effects. The description solely states the purpose without elaborating on 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, short sentence with no redundancy. It is front-loaded and avoids unnecessary detail, making it efficiently concise. However, the extreme brevity borders on under-specification, though it meets the basic expectation for conciseness.
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 far from complete for a tool with two parameters and no output schema. It does not explain the 'fields' parameter, expected response, or any operational details. Given the lack of annotations and minimal content, an agent would have insufficient 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about the parameters beyond what the schema provides. The schema documents 'profile_ids' but leaves 'fields' undescribed. With 50% schema coverage, the description fails to compensate or clarify the 'fields' parameter, offering no added contextual value.
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 returns 'WAROS balance' for a list of profiles, identifying the resource (balances) and scope (multiple profiles). It differentiates from sibling tools like waros_estimate or waros_customer by the focus on balances, 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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of conditions, exclusions, or scenarios where this tool is preferred. The purpose implies usage for balance retrieval, but no explicit instructions.
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, but it says nothing about the return payload, error handling for non-existent customer IDs, how far back 'historial' goes, or whether pagination applies. The description does not contradict anything, but it also adds no information beyond what the tool name alone conveys.
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?
One short, well-constructed Spanish sentence that is fully front-loaded and free of fluff. It is so terse, though, that it conspicuously misses the chance to add a short usage note without hurting the already excellent signal-to-noise ratio.
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 total absence of annotations and output schema, plus two undocumented parameters, the description is clearly underspecified for a 'detail/history' endpoint that might return voluminous data. An agent cannot tell what invoking it will yield or what effect dry_run has, so the information needed for correct invocation 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?
Schema coverage is only 33% with customer_id alone documented as 'Customer UUID'; the purpose of 'fields' and 'dry_run' is unexplained in both schema and description. With coverage this low, the description should compensate, but it says nothing about any 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 'Detalle e historial de un cliente' implies a specific fetch operation on a single customer resource, and the qualifier 'e historial' (and history) narrows the meaning beyond a plain synonym of the tool name. It differentiates at least implicitly from obvious siblings like customers_list, customers_orders, customers_metrics and customers_detail, since 'detail + history' reads as a fuller per-customer view. It loses one point because the description never explains what 'historial' actually covers (orders, interactions, financial movements, etc.), leaving real ambiguity against its siblings.
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 whatsoever about when to use customers_detail against the very close siblings customers_list, customers_orders or customers_metrics. No explicit or implicit mention of alternatives, conditions or exclusions appears in 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?
No annotations are provided, so the description must carry the burden of disclosing behavior. The word 'seguro' (safe) vaguely implies it is non-destructive, but it does not state whether it is read-only, what side effects might occur, permission requirements, or any limitations. For a tool that executes a query, 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 that states the core function without fluff. It is appropriately concise, though it sacrifices detail 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?
For a generic query runner with no output schema, no examples, and an undocumented 'fields' parameter, the description is insufficient. An agent cannot reliably construct a valid call without additional context that the description does not provide. The tool's complexity and lack of structured metadata demand a richer description.
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% (only 'spec' has a description, 'fields' has none). The description does not explain the format of the JSON QuerySpec string or the meaning of 'fields'. It adds no value beyond the schema, failing to compensate for the low 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 states a clear verb (Ejecuta) and resource (QuerySpec), and explains it returns analytical rows. This distinguishes it from sibling analytics_* tools which are specific analyses, while this is a generic query runner. However, the term 'QuerySpec' is not defined, so the purpose relies on prior knowledge of what a QuerySpec is.
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 the many sibling analytics tools (e.g., analytics_waros, analytics_rfm) or how it relates to queries_schema/waro_schema. The agent is left to guess whether this is the right entry point for a query or if the specialized tools are 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool lists orders with certain fields but does not mention pagination behavior (despite offset/limit/all params), response format, error handling, rate limits, or side effects. The existence of parameters like dry_run and all implies behaviors that are left unexplained, so the description is insufficiently transparent.
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, which is appropriately concise and front-loaded with the core purpose. It avoids unnecessary verbosity. However, given the tool's complexity, a slightly more informative phrasing would not have hurt, but the brevity is acceptable and does not detract.
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 12 parameters, low schema coverage, and no output schema. The description does not mention pagination, filtering logic, response structure, or how parameters interact. It is far from complete for an agent to correctly invoke the tool with appropriate parameters or to interpret results, making the description inadequate for the tool's complexity.
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 33% (4 of 12 parameters have descriptions). The description lists what the response includes but does not explain any parameters. It fails to compensate for the low schema coverage; parameters like timezone, dry_run, offset, and sort_direction remain ambiguous. 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 states the tool 'lists orders' and enumerates the fields included (status, date, payment, customer, items, total). This is a specific verb-resource combination that conveys the tool's function. However, it does not explicitly differentiate from closely related siblings like sales_detail, which also deals with orders, so it stops 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 offers no guidance on when to use this tool versus alternative order-related tools such as sales_detail or sales_metrics. There is no mention of use cases, exclusions, or conditions under which another tool would be more appropriate. The agent is left to infer usage from the bare 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 must carry the full burden of behavioral disclosure, but it only says the tool returns aggregated metrics. It does not state whether the operation is read-only, how aggregation is computed, whether dates are inclusive, or what the response looks like. An agent cannot infer the side-effect profile or output behavior.
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 free of filler, but it is under-specified rather than economically complete. It front-loads aggregate and period/grouping concepts but provides no additional structure or detail that would help an agent invoke the tool correctly.
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?
This is a 10-parameter tool with no output schema and no annotations, yet the description is a single noun phrase. There is no information about required inputs, date formats, comparison behavior, or response shape, making the definition inadequate for correct invocation. The large sibling set is also left undifferentiated.
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 10% (date_from), and the description hints only at period parameters and group_by. The meaning of fields, sort_by, compare_to, dry_run, limit, and timezone semantics are left undocumented in both schema and description. The description adds minimal value beyond a general grouping hint.
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 communicates that this tool returns aggregated sales metrics by period and groupings, which distinguishes it at a high level from record-level siblings like sales_list and sales_detail. It lacks an explicit verb, so it does not reach the top tier, but the resource and scope 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'por periodo y agrupaciones' implies this is the summary/analytics choice rather than the record-level sales_list or sales_detail, but it never explicitly states when to use this tool instead of alternatives. The usage guidance is only implied, not spelled out.
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 full burden. It implies a read operation ('detalle') but does not disclose behavior like return format, pagination, or side effects. No mention of required permissions or data scoping.
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 core purpose, but its brevity leaves out essential operational details. No waste, though arguably 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?
Inadequate for a tool with 3 parameters and no output schema. The description does not clarify expected return values, the role of 'fields' and 'dry_run', or any constraints. An agent cannot reliably invoke this tool correctly based on the information provided.
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 order_id described). The description does not explain the 'fields' or 'dry_run' parameters, which remain undocumented in both schema and description. It merely echoes the order_id UUID concept already 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?
Description states 'Detalle de una orden por UUID' (Order detail by UUID), clearly indicating a read operation for a specific order. This distinguishes it from siblings like sales_list (list of orders) and sales_metrics (aggregated metrics).
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 vs alternatives. The description provides no context on scenarios requiring order details vs list/metrics, nor any selection criteria.
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 the response value ('returns ok') but says nothing about failure behavior, such as whether an unreachable service produces an error or a non-ok payload. For a zero-parameter ping tool this is a reasonable but not fully transparent disclosure.
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 two short fragments with no wasted words and the core fact (health check, returns ok) is front-loaded. It is appropriately minimal for this tool's trivial surface area.
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 tool with zero parameters and no output schema, the description covers what an agent needs to invoke it correctly: the call has no inputs and yields 'ok'. The only minor omission is failure semantics, which is low-impact for a health check.
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 schema coverage is trivially 100%, so there is nothing for the description to document. Per the rubric, a zero-parameter tool earns a baseline of 4; nothing is missing on this dimension.
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 verb and resource: 'Health check — returns ok.' This unambiguously conveys that the tool verifies service liveness and returns a fixed 'ok' response. It is inherently distinguishable from the analytics, sales, and customer sibling tools, so no explicit differentiation is needed.
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 when-to-use guidance or alternatives are given. However, the purpose itself implies the usage — a health check is called to verify connectivity or service status before other operations. Since zero siblings serve this role, the absence of exclusion language is a minor gap rather than a fatal 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, the description carries the transparency burden. 'Introspect' and 'list all' imply read-only, non-mutating behavior, which is useful, but it does not mention auth assumptions, error/failure behavior, or what exactly the returned contract data 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 one short sentence with no filler: it states the action, the target resource, and both behaviors. It is front-loaded and easy to process.
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 low complexity and a single optional parameter, the description covers the main decision points. It does not clearly describe the shape of the introspection output, but the lack of an output schema makes that less critical; still, a tiny bit more info about accepted command values would round it out.
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 schema already documents the `command` parameter, and the description adds the key semantic distinction: omitting `command` lists all contracts, while providing it details one. The 'sales list' example gives a concrete hint, though it leaves the full set of valid command values and their exact formatting 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 gives a specific verb ('Introspect'), a clear resource ('API contracts'), and the two supported modes (list all, detail one). It clearly positions the tool as discovery/meta-level introspection, which distinguishes it from the data/analytics 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 intended use is reasonably implied: use it when you need to discover available Waro tools/contracts or inspect one in detail. However, it never explicitly says when to use it over similar-looking introspection siblings, and it offers no exclusions or context-sensitive guidance.
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:

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

Score Badge

Copy to your README.md:

[![waro-mcp MCP server](https://glama.ai/mcp/servers/uno0uno/waro-mcp/badges/score.svg)](https://glama.ai/mcp/servers/uno0uno/waro-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/uno0uno/waro-mcp'

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