Skip to main content
Glama

reporte

Producir un reporte estructurado completo — pago x402 $3.0 USDC

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of disclosing side effects, prerequisites, or return behavior, and it does none of that. The cryptic clause 'pago x402 $3.0 USDC' is not explained and appears to mix payment metadata with tool semantics, which adds confusion rather than transparency.

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

Conciseness2/5

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

The description is shortozik, but it is under-specified rather than genuinely concise. The opening phrase is clear, yet the trailing payment clause is unexplained and distracting, and no structured details about the report or input are provided.

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

Completeness1/5

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

For a tool with one required parameter and no output schema, the description must explain how to invoke it correctly, but it does not. The purpose is too vague retics, the input contract is unknown, and the payment reference introduces a significant unexplained element, making the description inadequate for reliable invocation.

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

Parameters1/5

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

The input schema has a single undocumented 'input' string and schema description coverage is 0%. The description also fails to explain what 'input' should contain, how it should be formatted, or how it relates to the report being generated, so the agent has no real semantic guidance.

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

Purpose3/5

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

The description uses a specific verb and resource ('Producir un reporte estructurado completo'), so the basic action is identifiable. However, it does not say what the report is about, what structure it will have, or how it differs from sibling tools like resumen or analisis_datos, leaving the purpose only partially clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No when-to-use guidance is provided, and no alternatives or exclusions are mentioned. The phrasing implies a report is wanted, but there is no indication of when this tool should be preferred over related siblings such as analisis_datos, resumen, or responder.

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.