presupuestos.red

Investiga recursos y su incidencia

consultar_usos_insumos

Read-onlyIdempotent

Investiga catalogId o varios catalogIds juntos, con expectedDataFingerprint vigente. scope limita a presupuesto (por defecto), conceptos o partidas con descendientes. Devuelve conceptos relacionados, importe visible afectado y contribución de costo directo por recurso y conjunta para TODO el alcance. La unión excluye descendientes ya contenidos en otro recurso seleccionado: las contribuciones individuales pueden solaparse. Es contribución actual, no ahorro ni resultado de eliminar recursos. cursor/limit paginan sólo evidence; los agregados no cambian entre páginas. Fronteras de costos horarios y porcentajes permanecen cerradas. null significa no calculable; completeness describe integridad económica y evidence.hasMore sólo páginas pendientes. 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": {
      "expectedDataFingerprint": "<expectedDataFingerprint>",
      "presupuestoId": "<presupuestoId>",
      "version": "<version>"
    },
    "name": "consultar_usos_insumos"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Número de filas de evidencia por página. Los agregados cubren todo el alcance.
`scope`	No	Alcance sobre el que se calculan los agregados y se buscan usos del recurso.
`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.
`catalogId`	No	Identifica un insumo o básico del catálogo. Toma su catalogId de la tabla catalogo o de una fila del APU.
`catalogIds`	No	Insumos o básicos cuya incidencia quieres investigar en conjunto. Toma sus catalogId de la tabla catalogo o de las filas del APU.
`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`	Yes	Huella del estado de los datos económicos que usaste como base. Tómala de context.dataFingerprint en la lectura que sustenta la consulta.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely useful non-annotation behavior: access depends on owner account/public status/read link, cursor/limit paginate only evidence while aggregates stay stable, null means not calculable, completeness signals economic integrity, and the union excludes descendants already covered causing potential overlap. It does redundantly restate 'no guarda cambios', but the auth and pagination semantics are substantive additions.

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 core purpose is front-loaded, and most sentences carry real information. But the description is a dense, run-on block with cryptic clauses ('Fronteras de costos horarios y porcentajes permanecen cerradas') that are hard to parse, and it restates the read-only hint already in annotations.

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?

Given a 10-parameter, high-complexity tool with a 100%-covered schema and an output schema, the description still supplies the conceptual model an agent needs: scope semantics, aggregate stability across pages, null/completeness meaning, access prerequisites, and the current-contribution caveat. It is close to complete, though a couple of phrases remain opaque rather than clarifying.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents all parameters well, establishing a baseline of 3. The description does add meaning beyond the schema — the union-exclusion rule for multiple catalogIds, the default scope being presupuesto, and the cursor/limit-evidencia-only constraint — but these are behavioral rather than per-parameter clarifications.

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 specific verb ('Investiga') and resource (catalogId/catalogIds and their incidence across a scope), and it names what gets returned: related concepts, visible affected amount, and direct-cost contribution. It is clearly a resource-usage/incidence query, distinguishable from neighbors like consultar_apu or buscar_conceptos, though it never explicitly contrasts itself against those siblings.

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?

It provides usage-relevant context ('Usa el contexto del presupuesto abierto', scope defaults to presupuesto) and explains what each scope mode covers. However, it never states when to reach for this tool versus alternatives, and it gives no explicit when-not guidance beyond the scope enumeration.

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?