presupuestos.red

Inspecciona la estructura de un concepto

inspeccionar_componentes_apu

Read-onlyIdempotent

Devuelve el concepto y su ruta de partidas, filas directas con coeficiente, operación, datos de catálogo y costos del motor, y referencias citables. Pasa el sourceId de una fila como occurrenceId para abrir su matriz ordinaria y ver sus ancestros; las ramas hermanas, los costos horarios y los cargos porcentuales quedan cerrados. nextCursor continúa la página del mismo alcance. completeness indica el grado de expansión. 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": {
      "conceptoId": "<conceptoId>",
      "presupuestoId": "<presupuestoId>",
      "version": "<version>"
    },
    "name": "inspeccionar_componentes_apu"
  }
}

Input Schema

Name	Required	Description
`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.
`conceptoId`	Yes	ID de concepto devuelto como conceptoId en buscar_conceptos o conceptId en la tabla presupuesto. Usa el ID interno del mismo documento.
`occurrenceId`	No	sourceId de la fila de una matriz ordinaria devuelta por inspeccionar_componentes_apu. Úsalo para abrir esa rama del concepto.
`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.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing access preconditions (owning account, public document, or a valid read link), the fact that nothing is persisted, that no professional opinion is issued, and where expansion stops. It also explains what completeness and nextCursor report—context an agent cannot get from readOnlyHint/idempotentHint alone.

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?

Front-loaded with what is returned, then how to expand a branch, then access rules and the no-write disclaimer—each sentence carries distinct information. It is dense and slightly long, but no sentence is purely redundant.

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 7-parameter read tool with an output schema, the definition covers payload shape, expansion scope, pagination, auth requirements and non-persistence. Return-value detail is partly duplicated from the output schema, but nothing an agent needs to invoke it correctly appears absent.

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 is 3, but the description adds real meaning: it ties occurrenceId to the sourceId of a row returned by this same tool and to opening that branch, links nextCursor to cursor, and tells the caller to use the open budget context for presupuestoId/version.

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 sentence gives a specific verb (Devuelve) plus a concrete payload: the concept, its ruta de partidas, direct rows with coefficient, operación, catalog data, engine costs and citable references. That distinguishes it from a plain lookup like consultar_apu or buscar_conceptos, though it never names those siblings explicitly.

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 states an actionable usage pattern: pass a row's sourceId as occurrenceId to open its matriz ordinaria and see ancestors, and notes that sibling branches, hourly costs and percentage charges stay closed. Pagination is covered via nextCursor continuing the same scope. What's missing is explicit routing—when to pick this over consultar_apu or buscar_conceptos.

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?