empresas

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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses concrete behavioral details: up to 50 results per page with a total, a 1-credit-per-page cost, and the underlying dataset size. These details are not present in the annotations and help the agent plan pagination and credit usage.

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 three sentences with no filler: purpose and filtering capacity, then result pagination with total, then cost. The most decision-relevant information is front-loaded and every sentence carries operational 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 19-parameter, read-only search tool with no output schema, the description supplies the essential invocation context: what is searched, the filter families, result size, total count, and credit cost. Combined with the 89% schema coverage, an agent has enough to select and invoke the tool correctly.

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

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

Schema coverage is high (89%), so the schema already documents most parameters. The description adds the important interaction semantic that filters are combinable ('filtros combinables') and illustrates the boolean stamp families, which goes slightly beyond the individual parameter descriptions without restating schema values.

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 begins with a specific verb and resource ('Busca empresas argentinas') and defines the scope over a 1.3M-company registry with combinable filters. It also distinguishes this general company search from narrower siblings such as buscar_importadores by framing importador/exportador as optional boolean stamps rather than the tool's sole focus.

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 states the use case: find Argentine companies by corporate name and/or a combination of filters, with pagination and cost. It does not explicitly name alternative tools or provide when-not-to-use exclusions, so it provides clear context but not full 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 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 declare readOnlyHint=true, so the description doesn't need to restate safety. It adds valuable behavioral context: the tool only returns tenders 'todavía sin adjudicar', it costs '1 crédito por página', and it supports filtering by 'solo-abiertas'. This goes beyond the schema and 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 a single, dense sentence that front-loads the core purpose and then lists filters and cost. Every clause earns its place; no filler or repetition.

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 5 optional parameters and no output schema, the description covers the domain, filters, and cost. It doesn't describe the return format or pagination behavior, but the schema and annotations cover the essential invocation details. A small gap remains around what fields are returned per result.

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 80%, so the schema already documents most parameters. The description adds meaning by explaining the domain context (e.g., 'rubro' values are suministros/servicios/obras/locaciones, 'abiertas' means future opening of offers), but it doesn't add much beyond what the schema already provides. 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 states a specific verb ('Busca'), a precise resource ('llamados a licitación del Estado argentino'), and the key attributes (organismo, objeto, rubro, expediente, fecha de apertura). It also distinguishes itself from siblings by focusing on unadjudicated public tenders, which is unique among the listed tools.

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 states what the tool searches (unadjudicated Argentine state tenders) and lists filterable dimensions (text, rubro, organismo, solo-abiertas). It does not explicitly name sibling alternatives or when-not-to-use, but the context signals and sibling list make the use case clear enough.

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 already declare readOnlyHint=true, so the read-only nature is covered. The description adds significant behavioral context: the credit cost (1 credit, plus extra for optional fields), the conditional behavior for person CUITs, and the list of purchasable additional fields with their individual credit costs. This goes well beyond the annotations, though it omits potential error cases (e.g., invalid CUIT format or unavailable data).

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 front-loaded with the main purpose and lists contents in a single, well-organized paragraph. It is relatively long due to the enumeration of data categories and credit details, but each clause serves a purpose (what data, cost, person case). It could be slightly more concise by grouping the field list, but the structure is logical and efficient overall.

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 complex tool with no output schema, the description provides a comprehensive overview of the returned data categories and the credit model. It explains the optional fields and the person fallback, which are essential for correct usage. It does not specify the exact response structure or error handling, but given the absence of an output schema and the breadth of data, the description is sufficiently complete to guide an agent.

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 input schema already provides complete descriptions for both parameters (cuit and campos), including format and the list of available fields with credit costs. Schema coverage is 100%, so the baseline is 3. The description adds a concrete example (campos=beneficiarios) and reinforces the credit behavior, but this is marginal value over the schema and does not substantially improve understanding.

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's purpose: it returns a complete file of an Argentine company by CUIT, listing the specific categories of information (registral identification, activity, directors, partners, corporate acts, BCRA credit situation, rejected checks, foreign trade, contracts, sanctions). It also distinguishes the person-CUIT case, directing to a person file, which differentiates it from the sibling ficha_persona. The verb 'devuelve' (returns) and resource 'ficha de empresa' are explicit and unambiguous.

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 implicitly defines when to use the tool: when you need a company file by CUIT. It explicitly handles the person case by stating that if the CUIT belongs to a person, it returns the person file (ficha: persona), which effectively routes the agent to the correct behavior. However, it does not name alternative tools (like ficha_persona) as a recommended fallback, nor does it state when not to use this tool, leaving the selection partially 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?

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, so the description correctly doesn't mention mutation. It adds context on data sources (INDEC, mercado), aggregation behavior (promedio de días hábiles o cierre), and the free nature. It could clarify response structure (e.g., time series format), but doesn't contradict 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 comprehensive and efficiently packs a lot of information into a few sentences. It fronts the core purpose and lists series, then covers aggregation and defaults. It's longer than ideal but every sentence serves a purpose; could be split into better structure, but acceptable.

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 data retrieval tool with rich parameter schema (enums and defaults) and no output schema, the description covers all essential calling information: what data is returned, aggregation options, date behavior, and source. No critical gaps for an agent to invoke correctly.

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

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

Schema describes all parameters with descriptions and enums. The description adds value by clarifying aggregation semantics (diaria limited to 10 years, mensual uses average or close) and that 'hasta' defaults to last data point. This goes beyond the schema's minimal descriptions, so it enhances parameter understanding.

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 fetches Argentine economic series between two dates, enumerating the available series (dólar oficial, blue, MEP, CCL, IPC, UVA, etc.). It distinguishes from siblings by focusing on economic data rather than company/person lookups or currency conversion. Includes default behavior without dates.

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 explicitly mentions aggregation options (diaria with 10-year limit, mensual_promedio, mensual_cierre) and default date behavior. While it doesn't name specific siblings as alternatives, it clearly implies usage context for economic queries; the sibling list shows other tools with different purposes. Could be more explicit about when not to use it, but given no overlapping tools, it's sufficient.

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?

Las anotaciones ya declaran readOnlyHint=true y openWorldHint=false, y la descripción no las contradice. Aporta contexto adicional sobre el contenido devuelto (unidad, frecuencia, fecha del primer y último dato) y señala que es gratuito, aunque no describe comportamiento más allá del catálogo.

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?

La descripción es una sola oración compacta, con la idea principal al inicio, ejemplos útiles y los metadatos que se incluyen. No hay palabras redundantes ni información superflua.

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?

Para una herramienta sin parámetros, de solo lectura y con un catálogo como salida, la descripción es completa: indica el tipo de datos, ejemplos de contenido y los campos incluidos. No se echa en falta información esencial para invocarla.

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?

La herramienta no tiene parámetros, por lo que el esquema no exige explicación adicional. La descripción no necesita documentar parámetros y el catálogo queda suficientemente definido por el texto.

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?

La descripción identifica claramente el recurso: un catálogo de series económicas argentinas disponibles para consulta, con ejemplos concretos como dólar, inflación y UVA. Se distingue de la herramienta hermana serie_economica porque describe un listado/catálogo y no una serie puntual, aunque no menciona explícitamente a ningún hermano.

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?

El contexto de uso se infiere: se usa cuando se necesita conocer qué series económicas están disponibles y sus metadatos. No se indica cuándo preferirla sobre serie_economica ni se ofrecen exclusiones o alternativas, por lo que la guía es solo implícita.

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.