Skip to main content
Glama

contar_negocios

Count businesses by activity or SCIAN code across Mexico, a state, or a municipality using DENUE data; filter results by employee-size range.

Instructions

Cuenta los negocios de un giro en el país, un estado o un municipio (DENUE).

Args: actividad: Giro en lenguaje natural ('tortillerías', 'farmacias') o código SCIAN de 2 a 6 dígitos; varios códigos separados por comas se suman ('464111,464112'). area: País (por defecto), estado o municipio, por nombre o clave ('Naucalpan'). personal: Tamaño por personal ocupado (opcional): 1 = 0 a 5, 2 = 6 a 10, 3 = 11 a 30, 4 = 31 a 50, 5 = 51 a 100, 6 = 101 a 250, 7 = 251 y más.

Input Schema

NameRequiredDescriptionDefault
areaNo
personalNo
actividadYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A3.9/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate 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.

Purpose4/5

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.

Usage Guidelines3/5

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.