Skip to main content
Glama

Indicadores Argentina

Ficha de empresa

ficha_empresa
Read-only

Ficha completa de una empresa argentina por CUIT: identificación registral, actividad principal y todas las declaradas ante ARCA, dirigentes y socios con el directorio vigente (último acto que designó a la administración; la sindicatura aparte), actos societarios del Boletín Oficial (constitución, reformas, quiebras, concursos), situación crediticia BCRA con detalle banco por banco, cheques rechazados cheque por cheque, comercio exterior, contratos con el Estado y sanciones. Cuesta 1 crédito. Con campos=beneficiarios agrega los beneficiarios finales estimados (+2 créditos) y con campos=presentaciones_igj los balances y asambleas presentados ante la IGJ con la evolución del capital social (+1); cada campo adicional se cobra sólo si vuelve con dato y la respuesta dice cuánto se cobró (creditos_cobrados) y qué campos vinieron vacíos sin cargo (campos_sin_cargo). Trae los 20 actos más recientes (con la descripción acortada y el link al aviso) y hasta 20 dirigentes, con eventos_total y dirigentes_total; detalle=completo devuelve todo, sin cargo si se pide dentro de los 5 minutos de la misma consulta. Cada dirigente trae su persona_id para pedir su ficha con ficha_persona. Si el CUIT es de una persona humana devuelve su ficha de persona (ficha: persona), salvo en ChatGPT, donde una persona se consulta sólo por persona_id y la ficha de empresa no incluye documentos de personas.

Input Schema

NameRequiredDescriptionDefault
cuitYesCUIT de la empresa, 11 dígitos (con o sin guiones)
camposNocampos adicionales separados por coma; cada uno suma créditos. Disponibles: empleados (+1), geo (+1), beneficiarios (+2), estados_contables (+2), situacion_historica (+1), paritarias (+1), score (+5), balances_cnv (+1), presentaciones_igj (+1), registros (+1), juicios (+1)
detalleNocompleto = todos los actos y dirigentes con el texto entero. Por defecto, resumido
directorio_alNoun día AAAA-MM-DD (hoy o antes) para saber quiénes administraban la sociedad ese día según los actos publicados; sin costo extra. Si no hay designaciones publicadas antes, directorio_al.fecha viene en null

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / detalle
      Added value: +{
      +  "description": "completo = todos los actos y dirigentes con el texto entero. Por defecto, resumido",
      +  "enum": [
      +    "resumido",
      +    "completo"
      +  ],
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / directorio_al
      Added value: +{
      +  "description": "un día AAAA-MM-DD (hoy o antes) para saber quiénes administraban la sociedad ese día según los actos publicados; sin costo extra. Si no hay designaciones publicadas antes, directorio_al.fecha viene en null",
      +  "type": "string"
      +}
  3. Changed1 schema field changed
    • changedInput schema / properties / campos / description
      Previous value: -"campos adicionales separados por coma; cada uno suma créditos. Disponibles: empleados (+1), geo (+1), beneficiarios (+2), estados_contables (+2), situacion_historica (+1), paritarias (+1), score (+5), balances_cnv (+1), registros (+1), juicios (+1)"New value: +"campos adicionales separados por coma; cada uno suma créditos. Disponibles: empleados (+1), geo (+1), beneficiarios (+2), estados_contables (+2), situacion_historica (+1), paritarias (+1), score (+5), balances_cnv (+1), presentaciones_igj (+1), registros (+1), juicios (+1)"
  4. Changed1 schema field changed
    • changedInput schema / properties / campos / description
      Previous value: -"campos adicionales separados por coma; cada uno suma créditos. Disponibles: empleados (+1), geo (+1), beneficiarios (+2), estados_contables (+2), situacion_historica (+1), paritarias (+1), score (+5), balances_cnv (+1), registros (+1)"New value: +"campos adicionales separados por coma; cada uno suma créditos. Disponibles: empleados (+1), geo (+1), beneficiarios (+2), estados_contables (+2), situacion_historica (+1), paritarias (+1), score (+5), balances_cnv (+1), registros (+1), juicios (+1)"
  5. Changed1 schema field changed
    • changedInput schema / properties / campos / description
      Previous value: -"campos adicionales separados por coma; cada uno suma créditos. Disponibles: empleados (+1), geo (+1), beneficiarios (+2), estados_contables (+2), situacion_historica (+1), paritarias (+1), score (+5), balances_cnv (+1)"New value: +"campos adicionales separados por coma; cada uno suma créditos. Disponibles: empleados (+1), geo (+1), beneficiarios (+2), estados_contables (+2), situacion_historica (+1), paritarias (+1), score (+5), balances_cnv (+1), registros (+1)"
  6. Changed1 schema field changed
    • changedInput schema / properties / campos / description
      Previous value: -"campos adicionales separados por coma; cada uno suma créditos. Disponibles: beneficiarios (+2), estados_contables (+2), situacion_historica (+1), paritarias (+1), score (+5), balances_cnv (+1)"New value: +"campos adicionales separados por coma; cada uno suma créditos. Disponibles: empleados (+1), geo (+1), beneficiarios (+2), estados_contables (+2), situacion_historica (+1), paritarias (+1), score (+5), balances_cnv (+1)"
  7. Changed1 schema field changed
    • changedInput schema / properties / campos / description
      Previous value: -"campos adicionales separados por coma; cada uno suma créditos. Disponibles: beneficiarios (+2), estados_contables (+2), situacion_historica (+1), paritarias (+1), balances_cnv (+1)"New value: +"campos adicionales separados por coma; cada uno suma créditos. Disponibles: beneficiarios (+2), estados_contables (+2), situacion_historica (+1), paritarias (+1), score (+5), balances_cnv (+1)"
  8. Changed1 schema field changed
    • changedInput schema / properties / campos / description
      Previous value: -"campos adicionales separados por coma; cada uno suma créditos. Disponibles: beneficiarios (+2), estados_contables (+2)"New value: +"campos adicionales separados por coma; cada uno suma créditos. Disponibles: beneficiarios (+2), estados_contables (+2), situacion_historica (+1), paritarias (+1), balances_cnv (+1)"
  9. Changed1 schema field changed
    • changedInput schema / properties / campos / description
      Previous value: -"campos adicionales separados por coma; cada uno suma créditos. Disponibles: beneficiarios (+2)"New value: +"campos adicionales separados por coma; cada uno suma créditos. Disponibles: beneficiarios (+2), estados_contables (+2)"
  10. Changed1 schema field changed
    • addedInput schema / properties / campos
      Added value: +{
      +  "description": "campos adicionales separados por coma; cada uno suma créditos. Disponibles: beneficiarios (+2)",
      +  "type": "string"
      +}
  11. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare it a safe read (readOnlyHint true, destructiveHint false), and the description adds the behavioral layer the annotations cannot: a 1-credit base cost, per-field surcharges, the rule that add-ons are billed only when data returns, creditos_cobrados and campos_sin_cargo in the response, and the free re-request within 5 minutes of the same query. It also discloses result caps (20 most recent acts, up to 20 directors, eventos_total / dirigentes_total) and that directorio_al.fecha may come back null.

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

Conciseness4/5

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

Purpose is front-loaded in the first clause and the pricing/limit details follow in a logical order. It is a dense single paragraph with many parentheticals, which makes some rules (directorio vigente vs sindicatura, the ChatGPT exception) harder to scan than a short bulleted structure would be, but almost every sentence carries decision-relevant information.

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

Completeness5/5

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

For a complex, multi-registry tool with no output schema, the description supplies what the agent needs to call it correctly and interpret the answer: costs, charge/no-charge rules, truncation caps with totals, the persona_id handoff to ficha_persona, and the null-directorate case. Nothing material for correct invocation is missing.

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

Parameters4/5

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

Schema coverage is already 100%, so a 3 would be baseline; the description earns above that by tying campos to billing behavior (each extra field only charged if it returns data, with campos_sin_cargo reported) and by explaining that detalle=completo is free if requested within 5 minutes of the same consulta. It also explains the semantics of the directorio vigente / directorio_al date indirectly. Cost numbers themselves are largely repeated from the schema, which keeps this from a 5.

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

Purpose5/5

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

States a specific verb+resource (full company dossier by CUIT) and enumerates exactly which registries are covered: registral identification, ARCA-declared activity, directors/shareholders, Boletín Oficial corporate acts, BCRA credit standing, rejected cheques, foreign trade, public contracts and sanctions. It also explicitly separates itself from ficha_persona (person records) and notes the ChatGPT caveat, so an agent can pick it over siblings 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.

Usage Guidelines4/5

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

Gives clear conditional guidance: use campos=beneficiarios / campos=presentaciones_igj only when those extras are needed and budgeted, and use detalle=completo inside the 5-minute window when the full text is required. It routes person lookups to ficha_persona and clarifies the ChatGPT path via persona_id. It does not explicitly contrast with search siblings like buscar_empresas or buscar_dirigentes, so the boundary with those is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources