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

No annotations are provided, so the description carries more burden for behavioral disclosure. It implies a read-only lookup and explains DENUE's SCIAN classification, but it does not mention no-match behavior, whether multiple codes may be returned, rate limits, or authentication requirements.

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 in the first sentence, followed by useful context and parameter guidance. There is minor redundancy in repeating examples, but the description remains compact and structured.

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 simple one-parameter lookup with an output schema, the description covers the tool's purpose, intended usage, and parameter meaning adequately. It could be improved by mentioning edge-case behavior when no matching SCIAN code is found.

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 for the single parameter. It defines 'descripcion' as a natural-language business type and gives useful examples like 'farmacias' and 'taller mecánico'.

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: 'Busca el código SCIAN de una actividad económica', with clear examples such as 'tortillerías' and 'gimnasio'. It also distinguishes the tool's intended role from counting/searching businesses by explaining that it helps select the correct code first.

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 says to use the tool before counting or searching businesses when the word is ambiguous, which gives clear usage context. It references sibling capabilities conceptually but does not name the exact tools or specify 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?

No annotations are present, so the description carries the behavioral burden. It discloses useful input behavior (partial names accepted, accents ignored, estado narrows the search) but does not explain multiple-match handling, matching rules, or any access/rate constraints; with an output schema covering returns, this is adequate but incomplete.

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

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

Front-loads purpose, then usage, then parameter notes; the four short lines all add information. The Args block is justified because the schema has no parameter descriptions.

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 two-parameter lookup with an output schema, the description covers purpose, usage context, and both inputs. It leaves some behavioral edge cases (multiple matches, exact matching) unspecified and no annotations exist, but the core information needed to invoke it is present.

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 parameters, and it does: nombre is full/partial with accents ignored and examples, estado is optional with examples like 'Chihuahua' or '08'. It adds clear semantics beyond the bare schema, though it does not specify exact matching rules for estado.

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 ('Busca') and exact resource ('clave geoestadística (5 dígitos) de un municipio o alcaldía por su nombre'), so the agent can tell this is a geographic-key lookup rather than an indicator, business, or area tool. It does not explicitly name or contrast a sibling, which keeps it at 4 rather than 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?

Provides clear triggering context: use when a name is ambiguous or to confirm the clave before another query. It does not state when not to use it or name a specific alternative sibling, so it stops short of full when/when-not 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 exist, so the description carries the full burden. It does convey the read-only, look-up nature and the result cap (1–50), but says nothing about truncation behavior when the limit is hit, whether a total match count is returned, or any institutional/rate constraints on the DENUE source. Useful but incomplete for an unannotated tool.

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

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

Front-loaded purpose sentence followed by the return payload, then a compact Args block. No sentence is redundant; the Spanish text is dense and each line adds distinct information.

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 an output schema present, the description need not spell out return values (it does anyway, briefly), and it covers input semantics thoroughly. The only real gap is behavioral edge cases: what happens when results exceed the limit, and whether an empty or ambiguous 'area' string is resolved or rejected.

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% and the description fully compensates: every one of the five parameters is explained, including allowed SCIAN code lengths (2, 3, 4, 6 digits), the personal-size range 1–7 with a cross-reference to 'contar_negocios', the limit range, and the area defaulting to the country. This meaning is genuinely unavailable from 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 verb ('Busca'), the resource ('negocios'), the search keys (nombre o giro), the geographic scope (país, estado, municipio) and the source (DENUE), then enumerates the returned fields. That scope description implicitly separates it from radius-based 'negocios_cercanos' and from the count-only 'contar_negocios'.

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 supplies a conditional usage rule ('Opcional si se da actividad') and points to 'contar_negocios' for interpreting the personal-size codes. However, it never says when to prefer this over 'negocios_cercanos' (proximity search) or when the geographic area argument is required versus defaulting to the whole country, so guidance remains 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?

With no annotations, the description carries the full behavioral burden. It discloses that the tool uses the 'último valor' of an indicator, which is useful recency context, but it does not discuss permissions, read-only behavior, error conditions, or any limitations. Because an output schema exists, return-value details are appropriately out of scope.

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 core comparison action, followed by a compact Args section that covers both required parameters. It is appropriately sized and contains little waste, though the Args formatting is slightly verbose relative to the small parameter set.

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 two-parameter comparison tool with an output schema, the description covers both required inputs and the key special value ['estados']. The main remaining gap is usage guidance relative to sibling tools such as consultar_indicador and perfil_area.

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: 'indicador' accepts a catalog key or numeric INEGI ID, and 'areas' accepts names or keys with the special token ['estados'] for all 32 entities. This adds substantial meaning beyond the bare schema, though concrete ID or key examples for 'indicador' would help further.

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: compare the latest value of an indicator across multiple states or municipalities. The scope is clear enough to distinguish it from single-area or profile-oriented siblings, although no sibling is named 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?

The comparison scope implies that this tool is for multi-area comparisons rather than single-indicator lookup, but it never explicitly says when to use it instead of consultar_indicador or perfil_area. No exclusions, prerequisites, or alternative-selection guidance 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 provided, so the description carries the full behavioral burden. It discloses useful behavior such as the default national area and the 1–120 observation range, and 'Consulta' implies a read operation, but it does not state permissions, error behavior, or rate limits.

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 core purpose and then uses a structured Args section. The examples and constraints are useful and there is no wasted text.

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 three-parameter query tool with a required indicator and an output schema, the description covers all parameters and their formats well enough to call it correctly. The main missing piece is explicit routing guidance against sibling tools.

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, and it does: it explains the indicator key/ID formats, all accepted area formats with examples, the default national scope, and the observation count range and direction.

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 first sentence states a specific verb and resource: consult the most recent value or series of an INEGI indicator. It is clear what the tool does, but it does not explicitly differentiate itself from siblings such as metadatos_indicador or comparar_areas.

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 explains the parameters but gives no explicit guidance on when to use this tool versus alternatives like comparar_areas, indicadores_clave, or metadatos_indicador. Usage is only implied by the word 'Consulta'.

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 bears the full burden. It does disclose useful behavior: DENUE as the data source, that comma-separated SCIAN codes are summed into one total, and that area defaults to the whole country; however it says nothing about error behavior for unrecognized activities, empty results, or rate limits.

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?

Purpose is front-loaded in a single sentence, followed by a compact Args block where every line carries parameter information not present in the schema. There is 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?

The output schema is present, so return values need not be explained, and all three parameters are fully described. The remaining gap is operational context: when to prefer this over the sibling search/comparison tools.

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 entirely, and it does: it explains the natural-language or 2–6 digit SCIAN form of actividad with comma-summation semantics, the name-or-key form of area with the country default, and the full seven-bucket mapping for personal.

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 uses a specific verb ("Cuenta") plus resource ("negocios de un giro") and states the geographic scope (país, estado o municipio) and source (DENUE). This implicitly distinguishes counting from the sibling search tools (buscar_negocios, negocios_cercanos), but no sibling is named, so differentiation is left to inference.

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?

Counting versus listing is implied by the verb, and the default (país) is stated, but there is no explicit when-to-use guidance nor any routing to alternatives such as buscar_negocios for individual records or negocios_cercanos for proximity queries.

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 must carry behavioral context. It reveals that only verified indicators are listed and that ID/geographic coverage are returned, but does not explicitly confirm read-only behavior, pagination, ordering, or auth/rate-limit 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?

The purpose is front-loaded in the first sentence, followed by a compact Args section. Every sentence adds useful information, and the parameter details earn their place because the schema lacks descriptions/enums.

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?

This is a low-complexity one-parameter catalog-listing tool with an output schema, and the description covers the purpose, optional filter, and key output fields. The main missing piece is explicit routing relative to sibling tools.

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 single optional 'tema' parameter. It does this well by naming the parameter, marking it optional, and enumerating the accepted theme values; only minor details like exact matching/case sensitivity are absent.

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 ('Lista') and resource ('indicadores verificados del catálogo'), and adds that results include ID and geographic coverage. It does not explicitly distinguish itself from siblings like consultar_indicador or metadatos_indicador.

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 the optional theme filter and its categorical values, implying discovery/catalog use. However, it gives no explicit when-to-use versus consultar_indicador or metadatos_indicador, and 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 disclosure burden. It partially meets it: it discloses the concrete fields returned and that the input accepts either a catalog key or a numeric INEGI ID, but it says nothing about behavior on an invalid/nonexistent indicator, whether output is a single record, or the fact that this is a pure read (inferred rather than stated).

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 very short blocks with zero filler, and the returned-field list is front-loaded. Minor structural weakness: there is no verb at all — 'Ficha de un indicador' is a noun phrase — and the raw 'Args:' docstring formatting is slightly out of place alongside the prose.

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 needn't be spelled out (though the description helpfully does). For a single-param, read-only metadata lookup this is nearly sufficient; the only real gap is the missing pointer to the sibling that supplies valid catalog keys.

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 and largely does: it defines 'indicador' as a catalog key OR a numeric INEGI ID, which is the single most important disambiguation for the only parameter. It falls short of saying where catalog keys come from (presumably indicadores_clave) or what an ID looks like.

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 precisely what the tool returns: the metadata sheet for an indicator (official name, unit, frequency, source, covered period), which is a concrete, verifiable scope. However, it never contrasts with close siblings like consultar_indicador (likely the data-values counterpart) or indicadores_clave (likely where keys come from), so sibling differentiation is left to inference.

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 through the noun phrase 'Ficha de un indicador' — an agent can infer 'use this for metadata, not for values', but there is no explicit when-to-use statement, no exclusion of consultar_indicador, and no note that the catalog key should be obtained from indicadores_clave first.

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 burden. It usefully discloses ordering (closest to farthest) and the DENUE source, and notes radio_m caps at 5000, which implies a read/search operation. It does not address permissions, rate limits, or pagination behavior beyond the limite cap.

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?

Purpose is front-loaded in the first line, followed by a compact Args block. The docstring style is slightly mechanical but every entry earns its place by adding param meaning.

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 an output schema present, return values needn't be explained, and all five params are documented with constraints. Behavior and ordering are covered; only explicit read-only/permission context and sibling routing are 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 coverage is 0%, so the description must compensate and largely does: it documents all five params with concrete examples (latitud 19.4785, longitud -99.2396), explains 'que' empty-returns-all behavior, and gives hard bounds (radio max 5000m, limite 1-50). This adds substantial value beyond 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 verb+resource: returns businesses around a geographic point, sorted nearest-to-farthest from the DENUE dataset. The spatial framing ('alrededor de un punto') implicitly distinguishes it from non-spatial siblings like contar_negocios and buscar_negocios, 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 spatial 'nearby a point' framing implies usage, but the description never states when to pick this over buscar_negocios or contar_negocios, nor any prerequisites. Guidance is inferred 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?

With no annotations, the description carries the full behavioral burden; it does disclose that every figure carries its period, which is useful output context. However, it says nothing about data coverage, missing values, units, or failure behavior for an unknown area name.

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 metric list is front-loaded, the usage cue follows, and the argument note comes last, which is a sensible order. The metric enumeration is long but each item adds real information about scope.

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 structure need not be explained; the description covers purpose, typical question shape, and argument format. Remaining gaps are edge-case behavior and the boundary against the more specific indicator and business tools.

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 does: the single parameter is described as a state or municipality accepted either by name or by numeric key, with concrete examples ('Naucalpan', 'Jalisco', '15057'). That is the key parsing information an agent needs and it is absent from the 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?

The description states a concrete resource ('Perfil de un lugar') and enumerates exactly what is included: population by sex, indigenous share, foreign-born, unemployment, and business counts by sector, each with its period. This is far more specific than a tautology, though it does not explicitly contrast itself with siblings like consultar_indicador or contar_negocios.

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 a clear usage rule ('Úsala para preguntas generales') backed by two concrete example phrasings. The word 'generales' implicitly steers specific-indicator questions elsewhere, but no alternative tool is named and no exclusion is stated.

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