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

No annotations exist, so the description carries the full behavioral burden. It does add real value by disclosing the calculation basis (cancelled divided by active base at the start of the month), which an agent could not infer from the schema, but it says nothing about read-only nature, data freshness, or cost of a wide month range.

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

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

A single well-formed sentence with the metric definition front-loaded and zero filler. However, brevity here comes at the cost of the missing guidance and parameter explanation, so the size is efficient but insufficient.

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

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

The tool is simple: two optional parameters, no nesting, no annotations, and an output schema that already documents the return shape. Given that the only real unknown is parameter meaning, the definition is close to complete but leaves a gap around as_of and months.

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

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

Schema description coverage is 0% for two parameters, so the description must compensate and does not. Neither 'as_of' nor 'months' is mentioned, leaving their meaning, format, and default-driven behavior (months defaults to 12, as_of defaults to null) undocumented outside the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (cancelamentos / churn) at a specific granularity (mês a mês) and even defines the metric formula. It is distinguishable from siblings like churn_reasons or churn_by_segment by the monthly time axis, though it never explicitly contrasts itself with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied by the name and the metric definition: an agent can infer this is the tool for a monthly churn trend. There is no explicit when-to-use statement, no exclusion, and no pointer to churn_by_segment or churn_reasons for the other cuts.

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

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

No annotations are supplied, so the description carries the full behavioral burden, and it discloses almost nothing: not that this is a read-only aggregation, not what the accumulation window is, and not what the default as_of=null means. The only behavioral hint is the diagnostic framing, which is weak for a tool with zero annotation coverage.

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

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

A single front-loaded sentence with the metric first and the purpose after the dash; nothing is wasted. It is arguably too terse for the gaps it leaves, but the structure itself is clean.

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

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

An output schema exists, so return values need not be described, and the segment dimension is covered. The unresolved as_of semantics and the absence of any behavioral disclosure leave a real gap for a two-parameter analytics tool.

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

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

Schema description coverage is 0%, so the description must compensate. It does clarify the meaning of the segment values (plan, city, sales channel), which is useful, but the as_of parameter is left entirely unexplained — no format, no default-null semantics, no timezone or cutoff behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific metric (accumulated churn) and the three segmentation dimensions (plan, city, sales channel), which map exactly to the enum in the schema. It implicitly distinguishes itself from time-series siblings like churn_by_month and churn_reasons, though it never names them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The clause 'para achar onde o problema se concentra' gives a diagnostic use case, which is more than nothing. But there is no explicit when-to-use versus churn_by_month, churn_reasons, or churn_risk, and no stated prerequisites or exclusions.

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

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

No annotations are supplied, so the description carries the full burden, yet it discloses nothing beyond the subject matter: no indication of aggregation shape, whether results are counts or percentages, or how the period is computed. The only behavioral hint is the parenthetical category list, which is thin for an analytics tool with two undocumented parameters.

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

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

A single short sentence with the resource front-loaded and the enumerations kept compact; nothing is padded. It is efficient, though the compression contributes to the missing parameter context.

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

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

An output schema exists, so return values need not be spelled out and the category list covers the result shape. However, the temporal scoping inputs remain undefined, which is a real gap for a time-windowed aggregation tool an agent must parameterize.

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

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

Schema description coverage is 0%, so the description must explain the parameters and it does not. 'no período' weakly gestures at months, but as_of (nullable, default null) is never explained — no date format, no meaning of null, no interaction with months. The parenthetical list describes output categories, not input semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific resource (cancellation/churn reasons) scoped to a period and enumerates the five reason categories returned, which lets an agent distinguish it from siblings like churn_by_month and churn_by_segment. The verb is implicit (no explicit 'list/aggregate'), which keeps it just short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 churn_by_month, churn_by_segment, or churn_risk, nor any prerequisite or exclusion. The agent must infer selection from the name alone.

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

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

No annotations are supplied, so the description carries the burden, and it does disclose meaningful behavior: scores are rule-based (atraso, chamados técnicos, tempo de casa, plano) rather than statistical, and the scale is 0–100. That is above the norm for a read tool. It still omits that the tool is read-only, how results are ordered/limited, and what happens when as_of is null.

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

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

Three short sentences, front-loaded with the core resource and result, then the methodology note. Every sentence adds something; the only weakness is that the methodology detail sits before the usage hint, which is the less critical part for selection.

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

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

An output schema exists, so return values need not be explained, but with no annotations and 0% schema coverage the description should have covered the two parameters and the read-only/pagination profile. For a two-parameter analytical tool it is adequate but leaves real gaps.

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

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

Schema description coverage is 0% for two parameters, so the description must compensate and it does not: 'as_of' (a snapshot date, defaulting to null/current) is never explained, and 'limit' is only vaguely implied by 'maior risco' without stating it caps the returned list (default 20). The agent must guess both meanings from the field names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the specific resource and scope ('Clientes ativos com maior risco de cancelar') plus the payload ('pontuação (0–100) e os fatores'), which is far more specific than the bare name churn_risk. It stops short of differentiating from siblings like churn_reasons, churn_by_segment or retention_cohorts, so an agent must infer the boundary itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use para priorizar ações de retenção' gives a clear use context, but there are no when-not conditions and no mention of the sibling tools it competes with (e.g. churn_reasons for factor breakdowns, retention_cohorts for cohort views). The agent gets a purpose but not routing guidance.

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

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

With no annotations at all, the description must carry the entire behavioral burden. It does contribute real meaning by defining the metric as overdue AND unpaid and enumerating the four bucket boundaries, but it says nothing about whether 'as of' defaults to today, which currency/entity scope applies, or that the call is a non-destructive read.

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

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

One front-loaded sentence that defines the metric and its buckets with zero filler. Nothing is redundant or buried.

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

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

An output schema exists, so return-value explanation is not required, but the definition still leaves the only input unexplained and gives no routing guidance among four related delinquency/churn siblings. For an analytics tool with an undocumented date parameter, this is thin.

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

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

Schema description coverage is 0% and the single optional parameter as_of is never mentioned in the description, so its purpose (reporting date for the aging calculation) and its accepted format are undocumented everywhere. Default-to-current-date behavior is left entirely to inference.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource precisely ('faturas vencidas e não pagas') and the exact aging buckets it reports (01-30, 31-60, 61-90, 90+), so an agent knows the shape of the result. It stops short of differentiating itself from the adjacent delinquency_by_month and delinquent_customers siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to choose this tool over delinquency_by_month (time series) or delinquent_customers (per-customer list), even though those siblings are named in the same server. No prerequisites or exclusions are given.

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

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

No annotations are supplied, so the description carries the full disclosure burden. It states the metric but says nothing about scope (all customers? a segment?), the default window (the schema's months=12 is never acknowledged), whether results are cumulative or bucketed, or how the as_of cutoff affects counting. For an analytics tool with zero annotation coverage this is thin, though the read-only nature is implicitly clear from the phrasing.

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

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

A single, front-loaded sentence with no filler; the metric definition arrives immediately. It is efficient rather than padded, though its brevity edges toward under-specification rather than crispness.

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

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

An output schema exists, so return values need not be explained. But for a two-parameter analytics tool with no annotations and no parameter descriptions, the definition leaves the agent guessing about the time window and evaluation cutoff, which materially affect the numbers returned.

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

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

Schema description coverage is 0%, so both parameters are undocumented in the schema and the description does not compensate. 'Por mês de vencimento' hints that grouping is by due date, which is useful, but as_of (what point in time delinquency is evaluated) and months (lookback window) get no explanation at all.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a concrete metric: counting invoices per due-date month that were paid late or remain open. That is more specific than restating the name, since it defines what 'delinquency' means here (paid late OR still open). It does not distinguish itself from close siblings like delinquency_aging or delinquent_customers, which is a real gap given the crowded sibling list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance whatsoever: no statement of what question this answers versus delinquency_aging, delinquent_customers, or overview. An agent must infer the choice purely from the name. No prerequisites, no exclusions.

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

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

No annotations are provided, so the description carries the full burden. It does disclose that only active customers are included, that invoices must be overdue by at least min_days, and that results are ordered by value descending, but it does not state read-only behavior, pagination, or how limit interacts with the result set.

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

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

The definition is a single front-loaded sentence with no filler. The population, threshold, and ordering are packed efficiently into one line.

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

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

An output schema exists, so return-value detail is not required in the description. The purpose is understandable, but with no annotations and no schema descriptions, key invocation details such as the reference date behind as_of and the limit behavior remain undocumented.

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

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

Schema description coverage is 0% across three parameters, so the description must compensate. It explains min_days as the minimum overdue age, but leaves as_of and limit entirely uninterpreted, adding meaning for only one of three parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific population (active clients with overdue invoices), a threshold criterion using min_days, and a sort order (highest value first). It does not name a verb explicitly or distinguish this report from siblings such as delinquency_aging or delinquency_by_month.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description defines the filtered customer set but gives no explicit when-to-use guidance or exclusions. With many sibling delinquency and retention tools, an agent gets no help choosing this over delinquency_aging or churn_risk.

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

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

No annotations are supplied, so the description carries the full behavioral burden, and it discloses very little. It is implicitly a read-only reporting call, but nothing is said about whether metrics are computed over a trailing window, whether the snapshot is cached, what happens for a future or invalid as_of, or what the response shape looks like (no output schema exists).

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

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

Two short blocks, metric list front-loaded, no redundant prose. The 'Args:' docstring formatting is slightly mechanical but costs nothing and makes the parameter easy to locate.

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

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

For a one-parameter aggregate tool this is close to adequate: the metric set and the date parameter are covered. But with no annotations and no output schema, the description should have clarified the measurement windows (e.g. what 'churn 30d' means, whether MRR/ARPU are point-in-time) so the agent can interpret and trust the numbers it returns.

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

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

Schema coverage is 0% – the input schema only declares an untyped string/null with default null. The description compensates well for the single parameter by giving its format (YYYY-MM-DD), its meaning (reference date), and a concrete effective default (2026-11-01) that the schema does not express.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete resource: a monthly KPI snapshot, enumerating the six metrics returned (base ativa, MRR, ARPU, churn 30d, inadimplência, chamados abertos). That is enough for an agent to distinguish it from sibling breakdown tools like churn_by_month or delinquency_aging, though it never explicitly says it is the aggregate/summary counterpart to them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied by the word 'overview' – an agent can infer this is the summary/dashboard call versus the per-topic siblings, but the description never states when to prefer this over churn_by_month, ticket_stats, etc., nor any prerequisite or ordering guidance.

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

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

No annotations are supplied, so the description carries the full burden, and it does disclose the output concept (survival percentages at fixed horizons), which is more than a bare label. However, it says nothing about whether this is a read-only computed aggregate, whether as_of defaults to today, or how cohorts with insufficient history are handled.

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

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

A single front-loaded sentence with a colon introducing the metric — no filler. It is efficient, though the extreme brevity leaves no room for the usage or parameter context the rest of the definition lacks.

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

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

The output schema covers return values, but with no annotations and zero parameter coverage the definition is incomplete for a two-parameter analytical tool: horizon semantics, snapshot behaviour, and cohort bucketing rules are all missing. The Portuguese-only text among English sibling descriptions also reduces discoverability.

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

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

Schema description coverage is 0% and the description never mentions either parameter. The meaning of 'as_of' (format, default of null, whether it snapshots the analysis) and 'months' (default 12) is left entirely undocumented; worse, the stated fixed windows of 1/3/6/12 months could be misread as overriding the months parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific analytical resource (retention cohorts keyed by entry month) and the exact metric computed (percentage of customers still active at 1, 3, 6 and 12 months). That is enough to separate it from siblings like churn_by_month or churn_reasons, though it never explicitly contrasts itself with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this cohort view versus churn_by_month, churn_by_segment, or run_sql, and no conditions, prerequisites, or exclusions are given. The agent must infer usage purely from the metric described.

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

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

With no annotations, the description carries the full burden and does real work: it declares the operation read-only, enforces a single statement per call, bans write keywords, and caps returned rows. It stops short of saying what happens on violation (error vs. truncation), whether there are timeouts, or what permissions the caller needs.

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

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

Two short sentences: capability and read-only scope first, then the schema pointer, then a compact limits line. Every clause adds usable information and nothing is padded.

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

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

For a free-form SQL tool with no annotations and no output schema, the definition covers the essentials an agent needs: safety profile, statement limit, row cap, and where to find schema. It omits error semantics and whether results are truncated or fail when exceeding `max_rows`.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: `query` is constrained to a single SELECT with no write keywords, and `max_rows` is explained as the row-count ceiling. It does not give SQL dialect, syntax examples, or default-behavior detail beyond the schema's `default: 200`.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Executa um SELECT livre no banco (somente leitura)'. The word 'livre' (free-form) implicitly contrasts with the twelve prebuilt analytics siblings, but no sibling is named, so differentiation is inferred rather than explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete usage context: read the schema at `isp://schema` first, one statement per call, no write keywords, capped at `max_rows`. It never says explicitly when to prefer this over siblings like `churn_by_month` or `ticket_stats`, so the routing decision is left partly to inference.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It does disclose what is aggregated and along which dimensions, but says nothing about read-only nature, data scope, time-window behaviour, or how the default window is applied.

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

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

A single, front-loaded sentence with no filler; the metrics are stated before the grouping options. It is efficient, though its brevity comes at the cost of the missing details noted elsewhere.

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

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

An output schema exists, so return values need not be explained, and the aggregation concept is clear enough to invoke with defaults. However, with an undocumented default window of 6 months and an opaque 'as_of' parameter, an agent cannot fully reason about what period it is querying.

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

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

Schema description coverage is 0% for three parameters, and the description only implicitly covers group_by by listing 'canal de venda, plano ou cidade'. The 'months' window and the 'as_of' reference-date semantics remain completely undocumented in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the specific metrics ('novos clientes e MRR novo') and the temporal grain ('por mês'), plus the three grouping dimensions. It is clearly distinguishable from siblings like churn_by_month or tickets_by_month by virtue of the sales/new-MRR focus, though it does not explicitly contrast itself with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no exclusions, and no named alternative (e.g. when to prefer churn_by_month or run_sql). The context is only inferable from the metric names themselves.

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

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

With no annotations, the description carries the full behavioral burden. It does not state that this is a read-only aggregation, nor does it explain the default 12-month window or how as_of affects results, leaving important behavior undisclosed.

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

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

The description is two short sentences with the purpose front-loaded and a compact usage hint. There is no redundant wording or filler.

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

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

Although an output schema exists, the description is incomplete for a tool with three parameters and no schema descriptions or annotations. It omits the meaning of as_of, the default value and effect of months, and the read-only aggregation behavior.

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

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

Schema description coverage is 0%, and the description only clarifies the optional city filter. It says nothing about the as_of parameter or how the months parameter controls the reporting window, so two of three parameters remain semantically undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific metric and resource: monthly ticket volume by category, optionally filtered by city. It is clear what the tool computes, but it does not distinguish itself from siblings like ticket_stats or sales_by_month.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Bom para achar picos' gives a useful usage context for peak detection. However, it does not name alternatives, exclusions, or when to use ticket_stats or overview instead.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It does disclose the exact metrics returned, which is valuable, but it never states the default reporting window (months=3), what as_of means, or that results are aggregated/read-only. Output shape is covered by the output schema, so that omission is acceptable.

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

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

A single short sentence with zero filler, front-loading the grouping key followed by the metrics. Nothing is wasted and nothing important is buried.

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

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

The tool is simple (2 optional params, output schema present, no nested objects), so a one-liner is close to sufficient. However, the undefined time-window semantics (months, as_of) are a real gap for an aggregation tool, since the returned numbers change materially with those parameters.

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

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

Schema description coverage is 0% and the description says nothing about either parameter. The critical behavior — that the window defaults to the last 3 months and can be shifted via as_of — is invisible to the agent and must be guessed from raw JSON titles. Only the 'hours' unit and the reported metrics are clarified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (tickets) and the exact grouping dimensions (city and category) plus the three metrics computed (volume, % resolved, mean resolution time in hours). That grouping distinguishes it implicitly from tickets_by_month, though the sibling is never named. The verb is only implied by 'stats', so it falls short of a perfect 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the city/category grouping signals that this tool fits questions about where tickets come from and how resolution varies by category, while tickets_by_month covers the time dimension. There is no explicit when-to-use statement, no exclusion, and no naming of the sibling alternative.

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