empresas_por_oportunidadDado un id (ej. 'opp-001') o título (exacto o aproximado) de una oportunidad de negocio, devuelve las empresas del directorio CEMIS relacionadas: primero las curadas a mano dentro de la propia oportunidad, luego las encontradas automáticamente porque su sector matchea por palabra clave con el texto de la oportunidad.
| Name | Required | Description | Default |
|---|---|---|---|
| oportunidad | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral details beyond the annotations: results are ordered with hand-curated companies first and automatically matched ones second, and automatic matching is based on keyword sector matching with the opportunity text. This gives the agent a clear expectation of result composition and ordering.
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, well-structured sentence that front-loads the input and main action, then uses a colon and 'primero...luego' to convey ordering. Every phrase adds value without unnecessary fluff.
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, read-only tool with no output schema, the description provides adequate completeness: it defines the input, the output domain, the result ordering, and the matching mechanism. No critical information is missing for selecting and invoking this 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?
The schema has zero description coverage for the 'oportunidad' parameter, but the description fully compensates by specifying that it accepts an id (e.g., 'opp-001') or an exact/approximate title. This is essential for correct invocation and far exceeds schema-only information.
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 ('devuelve'), a specific resource ('empresas del directorio CEMIS'), and a clear input criterion ('un id o título de una oportunidad'). It also distinguishes itself from sibling tools like 'buscar_empresas' and 'oportunidades_por_sector' by focusing on opportunity-to-company mapping.
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 implies when to use this tool: when you have an opportunity id or title and want related companies. However, it does not explicitly mention alternatives or when not to use it, so it lacks a direct exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct query path: general company search, full company profile, opportunity-to-company lookup, sector-to-opportunity lookup, reform impact, and list helpers. Even the related entity lookups are clearly separated by input and output.
Names are readable and consistently lowercase with underscores, but they mix verb-first conventions (buscar_empresas, listar_sectores) with noun-first descriptive names (ficha_empresa, impacto_de_reforma, empresas_por_oportunidad). The pattern is understandable but not uniform.
Seven tools is well within the ideal range and each tool covers a necessary query path for the CEMIS directory domain. There is no obvious bloat or thinness in the tool surface.
The core workflows are well covered: company search, company detail, sector/province enumeration, sector-opportunity relationships, opportunity-company relationships, and reform impact. Minor gaps exist, such as no direct way to list all reforms or all opportunities, but these can be worked around through the existing sector and reform lookup tools.