empresas

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

Annotations already establish a safe read (readOnlyHint=true, openWorldHint=false). The description adds genuinely non-structured behavior: the cost model ('1 crédito por página de 20'), the data-completeness caveat (only firm adjudications), and the entity-type limit (only legal persons). It stops short of auth requirements or pagination limits beyond the cost note.

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 sentences, front-loaded with what the tool returns, then filterability, then cost. Every sentence carries information. Slightly dense with field enumeration, but no waste.

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 read-only search with no output schema, the description covers the returned fields, the scope limits, the filter surface, and the credit cost. Pagination behavior beyond 'page of 20' and result ordering are the only notable omissions.

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 88%, so the schema already documents nearly every parameter. The description restates the filter dimensions (texto, organismo, CUIT, rango de fechas, jurisdicción, nivel) without adding format or syntax detail, and it omits the pagination parameter entirely. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (adjudicaciones/contracts awarded by the Argentine State), enumerates the returned fields (CUIT, razón social, organismo, fecha, monto, moneda, objeto), and scopes it (Nación, CABA, provincias). The verb 'ADJUDICÓ' and the constraints ('sólo adjudicaciones firmes', 'sólo personas jurídicas') let an agent distinguish it from buscar_llamados (tenders) without opening a schema.

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

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

It gives clear context and negative scoping: only firm awards and only legal entities, plus the list of filterable dimensions. However, it never names an alternative tool (e.g., buscar_llamados for tenders, ficha_empresa for company detail), so the agent must infer routing from the resource noun.

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?

Beyond the readOnlyHint annotation, the description discloses the credit cost per page and what each result contains. It adds operational context without contradicting the annotations.

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 tight sentences: action, return fields, and cost. Every clause carries information and the most important qualifier ('por nombre') is front-loaded.

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 read-only search tool with one required parameter and no output schema, the description covers the main return fields and the cost model. It leaves pagination/result-envelope details to be inferred from the schema, but nothing essential blocks invocation.

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

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

The schema describes 'q' as a name with a minimum length, and the description adds the type of people being searched. However, 'pagina' has no description beyond its name and minimum, and the description only hints at pagination via 'por página,' so it does not fully compensate for the 50% schema coverage.

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

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

States a specific action ('Busca personas') with targeted roles (directores, socios, gerentes, etc.) and the returned fields (CUIT, nombre, cantidad de empresas vinculadas). This clearly differentiates it from sibling tools like buscar_empresas, which search a different resource.

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 makes the usage context explicit: search people by name and get identifying data. It does not name alternatives or exclusion criteria, so it falls short of the strongest 5-level guidance, but the context is clear enough for selection.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds genuinely new behavioral facts: credit cost per page, 10 free results vs 50 with a paid pack, and that a total count is returned. Return format beyond the total and rate-limiting details remain unspecified, keeping it below 5.

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 dense but front-loaded sentence covering search scope, filters, geography, corpus size, pagination and cost, followed by a short cost sentence. Efficient, though the filter enumeration makes the opening clause heavy.

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 23-parameter read-only search with no output schema, the description covers pagination, per-page result counts, credit cost and result totals, which are the practical gaps. It omits mutual-exclusivity rules (only one of cerca/recuadro/departamento) and result shape, but the schema handles the former.

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 91%, so nearly every one of the 23 parameters is already documented inline. The description groups the filters conceptually (sellos booleanos, zona) but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Busca empresas argentinas por razón social') plus the full filter surface and dataset scope (~1,3M empresas). An agent can distinguish it from buscar_dirigentes or buscar_importadores, which search different entity types.

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?

Explains cost (1 crédito por página), free vs paid page sizes and that a total is returned, which is useful operational context. However, it never says when to reach for this tool versus ficha_empresa or the narrower buscar_importadores sibling, nor when-not to use it.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds valuable behavioral context: the cost of 1 credit per page, result ordering by FOB descending, currency in USD, and aggregation details. This goes beyond the annotations by disclosing pagination cost and 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.

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

Three concise sentences, each adding unique value: the first defines the ranking logic, the second covers filters and output format, and the third states the cost. No filler words, purpose is front-loaded, and structure is easy to scan.

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

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

With 7 parameters and no output schema, the description compends the most critical return details (FOB amounts, ordering, CUIT resolution) and the credit cost per page. A minor gap is the lack of a page size or default result count, which would help agents understand pagination behavior. Overall, it is largely complete for a read-only ranking 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 86%, meaning most parameters already have meaningful descriptions (e.g., NCM prefix formats, date format AAAAMM, activity codes). The tool description adds a high-level summary of filtering capabilities but does not add substantive per-parameter meaning beyond what the schema already provides. Baseline 3 is appropriate given high coverage.

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

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

The description clearly identifies the tool's purpose: generating a ranking of Argentine importing companies based on monthly import dispatches, with specific aggregation dimensions (period, NCM position, country of origin) and resolved to CUIT. It distinguishes itself from sibling tools like buscar_empresas or ficha_empresa by focusing on importer rankings with monetary amounts.

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

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

The description implies usage through its specific purpose (when you need importer rankings), but does not explicitly mention when to prefer this over alternatives such as buscar_empresas or ficha_empresa. No exclusions or comparisons to siblings are provided, so guidance is implied rather than explicit.

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?

Annotations already mark it read-only, but the description adds behavior the annotations cannot: billing cost (1 crédito per page of 20), deduplication rules (circulares y prórrogas no son llamados nuevos) and date semantics (apertura = última informada). These are exactly the operational facts an agent needs before burning credits or misreading results.

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?

Front-loaded with what the tool does and the result granularity, then layers usage, cost and the sibling pointer. It is dense but nearly every clause carries operational information; the only mild redundancy is the restatement of rubro values already present in the schema.

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

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

There is no output schema, so the description carries the return-value burden and does it: it enumerates the returned fields (organismo, objeto, rubro, expediente, apertura de ofertas, link). Combined with cost, pagination size and dedup semantics, nothing needed to call it correctly is missing.

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 already 90%, so the baseline is 3. The description goes past the schema by explaining the OR relationship between organismo filters and palabras ('se suman a palabras (uno u otro)') and restating the rubro and row-granularity semantics, though some of this duplicates what the schema already says.

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 ('Busca llamados a licitación del Estado argentino') and pins the scope to Nación, CABA, PBA and the remaining provinces. It also distinguishes itself from its closest sibling by routing detail lookups to ficha_llamado, so an agent can separate the two without opening a schema.

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

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

Gives an explicit usage recipe for the main scenario ('seguir un vertical... jurisdicciones + organismos + palabras clave en el objeto + desde') and names the alternative tool ficha_llamado for per-process detail. The OR semantics of the vertical ('entra lo que es de esos organismos O tiene esas palabras') tells the agent how to combine filters, not just when to call it.

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

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

Annotations declare readOnlyHint=true, which the description aligns with (no side effects mentioned). The description adds context that it's free and returns exchange rates/factors, but it doesn't disclose potential data gaps for certain months or the behavior when no data is available (e.g., error handling), which an agent might need to know. No contradiction with annotations.

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 sentences, front-loaded with the main purpose and scope, then provides key constraints (120 months, return contents) and a free note. No fluff, every sentence adds value.

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 conversion tool with no output schema, the description explains what it returns (tipo de cambio o factor, totales, meses sin dato), which is sufficient. It covers the main inputs and limits. It could add a note on error cases (e.g., invalid format) but overall it's complete for an agent to call it correctly.

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

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

Schema description coverage is 100%, so schema already documents each parameter. The description adds context on the montos format and explains the 'a' enum values, but it largely re-states what the schema provides. For example, the description explains 'ars_hoy' as pesos ajustados por inflación, which is already in the schema, and defaults are in schema too. Thus a baseline 3 is appropriate.

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

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

The description clearly states the tool converts Argentine peso amounts across different months to dollars using monthly exchange rates or to today's pesos adjusted by IPC. It specifies the resource (montos in ARS) and the verb (convertir), and clearly distinguishes it from sibling tools like serie_economica or inflacion_entre_fechas which focus on data series or inflation between dates, not amount conversion.

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 specifies the input format (pares AAAA-MM:monto) and the destination options (usd_oficial, usd_blue, etc.), plus the limit of 120 months per call. It implies usage for conversions across months but doesn't explicitly say when NOT to use it or when to prefer siblings like inflacion_entre_fechas for pure inflation series, which would clarify routing.

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?

Annotations only declare readOnlyHint=true and openWorldHint=false, so the description carries the real behavioral burden and does so richly: cost of 1 credit, per-field add-on pricing, the rule that extra fields are charged only when data returns, and the presence of creditos_cobrados / campos_sin_cargo in the response. This is exactly the cost-and-billing context an agent cannot get from structured fields.

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 core identity is front-loaded in the first clause, and every following sentence carries non-redundant information (content domains, pricing, add-ons, fallback). It is dense and slightly run-on, but nothing is wasted.

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

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

With no output schema, the description responsibly names key return fields (creditos_cobrados, campos_sin_cargo, ficha:persona) and covers billing and add-on behavior. It stops short of describing the full response shape or pagination, but for a read-only dossier tool it is nearly complete.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining what campos=beneficiarios actually returns (estimated final beneficiaries) and the conditional-charge semantics of additional fields. It does not fully expand every enum value (score, paritarias, etc.), which caps it below 5.

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 ('Ficha completa de una empresa argentina por CUIT') and enumerates the content domains covered (registral, actividad, dirigentes, BCRA, cheques, comercio exterior, etc.). It also distinguishes itself from the person-file sibling by explaining the ficha:persona fallback, so an agent can tell it apart from ficha_persona and buscar_empresas without opening schemas.

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

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

The description implies usage (call with a CUIT to get the full dossier, use campos= to extend) and gives the person-fallback condition, but never states when to prefer this over buscar_empresas or buscar_dirigentes, nor any prerequisites. Usage is inferable rather than explicit.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description goes well beyond them: it discloses a cost of 1 credit, the edge case that a nonexistent slug is not charged, and that some fields (valor del pliego, garantías) only appear when the notice publishes them.

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 dense sentence with the purpose front-loaded, followed by the returned-field inventory and then cost. It is long but nearly every clause carries information; the parenthetical field list is the only part that could be trimmed.

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?

No output schema exists, so the description carries the return-shape burden and does so thoroughly: cronograma milestones, participation link/platform, budget, pliego value, guarantees, outcome, and publication history. Combined with cost and the uncharged-slug edge case, an agent has everything needed to call and interpret it.

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

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

Single parameter with 100% schema description coverage, so the schema already defines 'slug' identically to the description. The description adds no format, syntax, or sourcing detail beyond what the schema says, making the baseline 3 correct.

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+resource: retrieve the detail of an Argentine state procurement process from a buscar_llamados slug. This cleanly separates it from the search sibling (buscar_llamados) and from the other ficha_* tools (ficha_empresa, ficha_persona) without opening any schema.

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

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

Explicitly names the prerequisite source of its input ('el slug de un resultado de buscar_llamados'), which tells the agent it must run the search first. It gives no explicit when-not condition or alternative tool, so it falls just short of a 5.

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

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

Beyond the readOnlyHint=true annotation, it discloses that each call costs 1 credit, that company CUITs return a company ficha instead, and what data domains are covered (AFIP tax status, declared activity, all linked companies). This is substantial behavioral context not present in annotations.

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 concise sentences with no filler. The core purpose and expected data come first, then the credit cost, then the edge-case behavior. Every sentence earns its place.

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

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

With a single parameter, no output schema, and a read-only annotation, the description covers the returned data categories, the credit cost, and the main edge case. An agent has sufficient information to invoke the tool correctly.

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

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

The schema already documents cuit as an 11-digit CUIT/CUIL with 100% coverage, so the baseline is 3. The description adds important meaning by clarifying that a company CUIT is accepted and returns a company ficha, which goes beyond the schema's 'person' wording.

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

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

The description states a specific verb and resource: retrieve a person's ficha by CUIT/CUIL, covering identity, AFIP tax status, declared activity, and linked Argentine companies with roles. It also differentiates from ficha_empresa by explicitly describing the company-CUIT fallback.

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

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

It gives clear context for when to call the tool: for any CUIT/CUIL, with an explicit branch for company CUITs returning company ficha data. It does not explicitly name alternative person-search tools like buscar_dirigentes, so it stops short of full exclusion 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?

Beyond the readOnlyHint annotation, the description discloses that inflation is chained, not summed; that it returns factor, accumulated percentage, annualized value, and each month; and that it will report missing published months instead of inventing data. This is meaningful behavioral context without contradicting the annotations.

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 four short sentences with no fluff: purpose and method come first, then parameter semantics, outputs, failure behavior, and cost. Every sentence carries information an agent needs.

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?

There is no output schema, so the description compensates by listing the returned items (factor, accumulated percentage, annualized, each month) and the missing-data behavior. It also gives the base-month rule and references the default 'hasta' behavior via the schema, making it complete enough to invoke correctly.

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

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

The schema already provides 100% coverage of the parameters, including format and the default for 'hasta'. The description adds useful semantics beyond the schema by explaining that 'desde' is the base month and by describing the chaining rule, so it earns more than the baseline 3.

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 is explicit about the tool's purpose: cumulative inflation in Argentina between two months, chaining INDEC's monthly IPC rather than summing it. It names the resource and the return values, but it does not explicitly distinguish itself from a sibling like serie_economica, 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.

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

The description clearly establishes the intended computation and gives an important usage rule: 'El mes desde es la base: de agosto a agosto son doce meses.' It does not explicitly state when not to use the tool or name an alternative, but the computation is specific enough that selection is mostly unambiguous.

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?

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds the 'Gratis' (free) trait and clarifies the scope (available balance and monthly consumption), which are useful beyond annotations. No contradiction 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 concise sentences, front-loaded with the primary purpose and followed by a key attribute (free). No filler or redundancy, every word earns its place.

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

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

For a zero-parameter, read-only balance tool, the description is adequately complete. It states what is returned (balance and consumption) and notes it is free. It does not specify the exact response format or units, but given the low complexity and no output schema, this is a minor omission rather than a functional gap.

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

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

There are zero parameters, so the schema fully covers them (100% coverage trivially). The baseline for 0 params is 4, and the description does not need to explain any parameters. It provides context about what the tool returns, which is sufficient.

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

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

The description clearly states the tool provides the available credit balance and monthly consumption for the API key. It is specific and distinct from sibling tools which are all about searching entities or data series, so an agent can easily tell this is the credits/usage tool.

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

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

No explicit when-to-use guidance or alternatives are mentioned. However, its unique purpose among siblings makes the context obvious; the description implies it is for checking account status, but it does not state conditions like 'use this to verify credits before making calls'. This is a minor gap given the tool's simplicity.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond that: the default window when dates are omitted, that monthly values are computed as an average of business days or a close, and that the day-count per month is reported, plus that access is free. It stops short of describing units or return shape, but for an annotated read-only tool this is solid added context.

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 purpose is front-loaded, but the middle is a single enormous run-on sentence enumerating roughly 150 series that the schema already lists verbatim. The category grouping (dólar, inflación, UVA, riesgo país, balance cambiario...) is somewhat useful navigationally, but most of the enumeration does not earn its place against a fully populated enum. The trailing sentences about aggregation and defaults are the parts that carry their weight.

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 tool returning numeric time series with no output schema, the description should say something about return shape or units (pesos, percentages, index levels), and it says nothing. It also omits any pointer to series_disponibles for discovery, forcing the agent to rely on the embedded enum. It is adequate for calling the tool, but not complete for interpreting the results.

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

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

Schema coverage is 100%, so the enum and date formats are already documented and the baseline would be 3. The description adds meaning beyond the schema for the aggregation parameter, explaining that mensual_promedio means an average of business days and mensual_cierre means the closing value, and that the day count per month is included. The prose grouping of the ~150 tipo values is largely redundant with the enum, but the aggregation semantics are real added value.

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 opening clause names the resource and scope precisely: Argentine economic series between two dates, with the full taxonomy of what can be requested. An agent knows immediately this is a data-retrieval tool, not a lookup or search tool. However, it never distinguishes itself from siblings like inflacion_entre_fechas (which overlaps the IPC series) or series_disponibles (which presumably enumerates the same catalog), so sibling differentiation is absent.

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

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

It gives useful operating defaults: 'Sin fechas devuelve el último año' and the aggregation modes with their meaning. But there is no when-to-use/when-not guidance against the overlapping siblings, and no statement of which tool an agent should reach for when it only wants inflation or the list of valid series. Usage is implied rather than routed.

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?

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false). The description adds behavior the annotations don't: cost status ('Gratis') and the shape of each entry (unidad, frecuencia, fecha del primer y último dato), which is genuinely useful context for a tool with no output schema.

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

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

Front-loads the purpose, then the coverage, then the returned fields and cost in a single tight sentence. The long parenthetical enumeration is dense but it earns its place by letting the agent match on a domain keyword without a separate call.

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

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

With no parameters, no output schema, and annotations covering safety, the description supplies what is otherwise absent: what each catalog entry contains and that access is free. The only gap is the missing explicit link to how you subsequently fetch a series.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly implies it is a no-argument listing operation, adding nothing that is needed or missing on the parameter side.

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 (catálogo de las series económicas argentinas) and enumerates exactly which domains it covers (dólar, inflación, UVA, ICL, CER, riesgo país, tasas, comercio exterior, etc.), which makes it clearly distinct from the data-returning sibling serie_economica. An agent can tell this is a discovery/catalog tool without opening any schema.

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

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

Usage is only implied: the phrase 'que se pueden consultar' suggests this is a discovery step before querying a specific series, but the description never says when to call it versus serie_economica or how to move from a catalog entry to a data fetch. No explicit when/when-not guidance is present.

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?

readOnlyHint=true already covers the read-only safety profile, so the description need not restate it. It adds genuine behavioral context beyond the annotation: the 8-result cap and the free (no-credit) behavior. openWorldHint=false is not contradicted; nothing in the description conflicts with the annotations.

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

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

Two short sentences with zero waste, purpose front-loaded ('Autocomplete') before the constraint and cost note. Every word earns its place.

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

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

For a low-complexity single-parameter autocomplete tool with readOnly annotation, the description covers what it returns (up to 8 Argentine companies matching partial text). Minor gaps: the return format is not described (no output schema) and the sibling routing to buscar_empresas is left implicit, but these are small against the tool's simplicity.

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

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

Schema coverage is 100% — the q parameter is already documented ('texto parcial, mínimo 2 caracteres'). The description reinforces the 'partial text' semantics but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb ('Autocomplete' / 'matchean') and a specific resource ('empresas argentinas') with a concrete limit (hasta 8). The autocomplete framing implicitly distinguishes it from the sibling buscar_empresas (full search), though it does not name the sibling explicitly.

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?

Provides a useful selection cue — 'Gratis (no consume créditos)' — telling an agent this is the zero-cost option among credit-consuming search tools, suitable for pre-filtering candidates. However, it does not explicitly state when NOT to use it or name the alternative (buscar_empresas) for full searches.

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