Skip to main content
Glama

Detalle CNAE 2009

detalle_cnae_2009
Read-only

Ficha de un código CNAE 2009 (obsoleto): título, descripción y correspondencia a CNAE 2025, con la URL canónica de la página (url). Sin clave. El enriquecimiento con IA (ai_summary, fiscal_signals) requiere un plan de pago.

Input Schema

NameRequiredDescriptionDefault
codeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, non-destructive, closed-world). The description adds real behavioral context beyond them: what the response contains, that no API key is needed ('Sin clave'), and that AI fields (ai_summary, fiscal_signals) are gated behind a paid plan. This gating/auth detail is exactly the kind of extra context that earns credit over annotations.

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?

Compact and front-loaded: what it returns, the URL, then the auth and premium caveats. Slightly dense with parentheticals but no wasted sentences.

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?

With no output schema, the description usefully enumerates the return fields and mentions the paid-plan gating, which is enough for an agent to call a single-param read tool correctly. Only the input code format is left unaddressed.

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

Parameters2/5

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

Schema description coverage is 0% for the single 'code' parameter, so the description carries the full burden — and it does not compensate. It implies the input is a CNAE 2009 code but gives no format, example, or separator guidance (the schema only shows a generic pattern ^[\d.]+$).

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 states a clear verb+resource: it returns a 'ficha' (record) for a CNAE 2009 code, enumerating the fields returned (título, descripción, correspondencia a CNAE 2025, URL). Tagging it '(obsoleto)' implicitly distinguishes it from the sibling detalle_cnae, though no explicit routing statement is given.

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?

Usage is only implied: the '(obsoleto)' marker signals this tool is for legacy 2009 codes, but the description never states when to prefer it over detalle_cnae (the current-version sibling) or names any alternative. No when-not guidance.

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.