Skip to main content
Glama
Sign In
MCP para Primavera Unifier

MCP para Primavera Unifier

by jbrasero
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

unifier_risk_center

Collects read-only risk evidence from Primavera Unifier shells, cost sheets, schedules, and selected risk business processes, then returns classified risks and draft actions without changing data.

Instructions

Centro de Riesgos Agentic de solo lectura. Coordina shell, Cost Sheet, Schedule Sheets y BPs de riesgo seleccionados; devuelve evidencia, riesgos clasificados y borradores de acción sin ejecutar ningún cambio.

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": {
      "project_number": "<project_number>"
    },
    "name": "unifier_risk_center"
  }
}

Input Schema

NameRequiredDescriptionDefault
risk_bpsNo
project_numberYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose the key trait: read-only, explicitly 'sin ejecutar ningún cambio', plus what it returns (evidence, classified risks, action drafts). It omits auth/permission requirements, rate limits and how the multi-source coordination actually behaves, which a no-annotation tool ideally would state.

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?

Two tight sentences with the read-only constraint front-loaded ahead of the scope and output summary. No filler; the only weakness is that brevity comes at the cost of parameter detail.

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

Completeness3/5

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

For an orchestration tool with two undocumented parameters, no output schema and no annotations, the description conveys the gist but leaves real gaps: the risk_bps object shape, the meaning of project_number, and what 'coordina' involves operationally are all absent.

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%, so the description must compensate, but it says nothing about project_number or the risk_bps array structure. 'BPs de riesgo seleccionados' loosely gestures at risk_bps but gives no format, enum values or selection semantics, and project_number is never mentioned.

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 names a specific resource (Centro de Riesgos Agentic) with an explicit verb set — coordinates shell/Cost Sheet/Schedule Sheets/risk BPs and returns evidence, classified risks and action drafts. Its orchestration scope is distinguishable from narrower siblings like unifier_find_bp_record, but it never names them to sharpen the boundary.

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?

There is no when-to-use or when-not-to-use guidance and no alternative named among the many unifier_* siblings. An agent can infer this is for consolidated risk review, but the description does not tell it when this tool beats unifier_project_health or unifier_read_shell_360.

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

Deploy Server

Other Tools