presupuestos.red

Lee los datos económicos del presupuesto

consultar_datos_presupuesto

Read-onlyIdempotent

Lee presupuesto, catalogo, componentes y explosion por páginas de 50 registros, hasta 100. Componentes devuelve matrices con cabecera (código, descripción y unidad), directUses e items directos con recurso, unidad, coeficiente, operación y costo del motor. directUses muestra conteos completos y hasta 20 referencias documentales directas a conceptos raíz o items de matrices padre con sus conceptos raíz; hasMore indica referencias omitidas. concept.importe es el importe visible del concepto completo, no incidencia del recurso ni una cifra sumable entre referencias. Las relaciones internas de costos horarios y porcentajes son documentary_only. consultar_usos_insumos consulta occurrences reales dentro de conceptos; no continúa exactamente esta lista documental. totalComponents, limit y cursor cuentan componentes fuente, no matrices ni referencias. Una matriz puede continuar en otra página con la misma cabecera. Las otras tablas conservan rows y totalRows. Continúa con nextCursor y expectedDataFingerprint de la primera respuesta. status, null y boundary conservan faltantes y cargos cerrados; costPerUnit es el costo por unidad del recurso o la base porcentual, no el importe del renglón. Las fuentes citables se consultan con consultar_apu e inspeccionar_componentes_apu. Usa el contexto del presupuesto abierto. El acceso depende de la cuenta propietaria, de que el documento sea público o del enlace de lectura vigente. No guarda cambios ni emite una opinión profesional.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "table": "<table>",
      "presupuestoId": "<presupuestoId>",
      "version": "<version>"
    },
    "name": "consultar_datos_presupuesto"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Tamaño de la página en registros de origen. En componentes se cuentan los renglones, aunque pertenezcan a la misma matriz.
`table`	Yes	Elige la vista económica según lo que investigas. La tabla de conceptos permite comparar valores de origen y del visor. La de matrices muestra la composición directa y la explosión acumula consumos e importes por insumo.
`cursor`	No	Posición desde la que se retoma la lectura. Usa nextCursor de la página anterior.
`version`	Yes	Número de la revisión publicada que quieres consultar. Usa el que acompaña al presupuesto en el contexto del visor.
`presupuestoId`	Yes	Identifica el documento. Tómalo del contexto que devuelve el visor al importar o abrir el presupuesto.
`readSharePath`	No	Enlace que da acceso de lectura a un presupuesto compartido. Para un documento privado compartido, toma este valor del contexto con el que lo abriste.
`conversation_id`	No	The conversation_id this server returned earlier in this conversation, unchanged, including after later user messages. Omit it if you have none. Recorded for the server developer's analytics.
`expectedDataFingerprint`	No	Fija el estado de los datos mientras recorres la tabla. Al continuar, toma context.dataFingerprint de la primera página.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, yet the description still adds material behavior: access depends on the owning account, public status, or a valid read link; a matriz may continue onto the next page with the same header; totalComponents/limit/cursor count source rows, not matrices or references; and continuation requires nextCursor plus expectedDataFingerprint from the first response. It also reinforces the safe profile with "No guarda cambios ni emite una opinión profesional", consistent with the annotations.

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

Conciseness3/5

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

The opening sentence front-loads the purpose, but the body is a dense run-on paragraph mixing pagination, field semantics, sibling routing, and access rules without headers or grouping. Almost every clause carries real information, yet the packing makes it hard for an agent to parse the page-continuation rules quickly.

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?

For a four-view, paginated, fingerprint-guarded read tool with an output schema, the description covers access prerequisites, pagination mechanics, cross-page matrix continuity, and non-continuation boundaries. Return-value explanation is partly redundant given the output schema, and the choice among the four tables is left to the schema's enum description, which is the only modest gap.

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 100%, so the baseline would be 3; the description earns extra credit by clarifying that "totalComponents, limit y cursor cuentan componentes fuente, no matrices ni referencias" and that pagination must be resumed with "nextCursor y expectedDataFingerprint de la primera respuesta" — both are operational semantics beyond the field-level schema text.

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 opening verb+resource list ("Lee presupuesto, catalogo, componentes y explosion") is specific and matches the four table enum values, so an agent knows exactly which data views this returns. It stops short of a crisp one-line scope statement because the differentiation from siblings is buried later in the paragraph, but the core purpose is unambiguous.

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?

It explicitly routes the agent: "consultar_usos_insumos consulta occurrences reales dentro de conceptos; no continúa exactamente esta lista documental" and "Las fuentes citables se consultan con consultar_apu e inspeccionar_componentes_apu". What it lacks is a positive "use this when investigating X" statement for its own four views — that guidance lives in the schema's table enum rather than the description.

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

All presupuestos.red tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?