Skip to main content
Glama
Sign In

Onplana

by io.github.Onplana
OverviewDiscussionsAdmin

get_schedule_risk

Read-onlyIdempotent

Read the Monte Carlo schedule risk runs of a project. Returns the newest run (status QUEUED, RUNNING, DONE or FAILED) and, when that run is not finished, the newest finished run. A finished run carries a summary: the P50, P80 and P90 finish dates, the plan date (the latest stored task finish, as the Gantt shows it) and its chance of being met, the finish as the links schedule it, the target date and its chance when one was set, how many risk events were sampled, and unlinkedCaveat: a sentence, or null, saying the run understates the slip because more than 5 percent of the working tasks have no links (a delay on an unlinked task moves nothing). includeResult=true adds the whole stored result of the finished run (finish histogram and curve, milestone dates, task criticality and duration sensitivity). runId reads one run by id instead. Read-only; runs are started from the project Risks tab or the REST API.

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": {
      "projectId": "<projectId>"
    },
    "name": "get_schedule_risk"
  }
}

Input Schema

NameRequiredDescriptionDefault
runIdNoOptional. One run of this project by id, in place of the newest.
projectIdYes
includeResultNoDefault false. Adds the whole stored result of the finished run.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: it discloses the newest-run-plus-fallback-to-newest-finished-run selection logic, what statuses a run can carry, what a finished summary contains, and the unlinkedCaveat semantics for unlinked tasks. It also states the mutation path lives elsewhere.

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?

Purpose is front-loaded and every clause carries information, but the summary enumeration is a long run-on sentence that could be split into a short list for faster scanning. No filler or repeated content.

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

Completeness5/5

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

There is no output schema, so the description must carry the return contract, and it does: run status, the finished-run fallback, each summary field including the plan date's chance of being met, and the optional heavy payload. An agent can call this correctly and anticipate the response shape.

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 67%, and the description compensates well: includeResult is expanded into the actual payload it adds (histogram, curve, milestone dates, criticality, duration sensitivity) and runId is explained as an override of the newest-run default. projectId gets no explanation, but its meaning is self-evident given the project scoping.

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

Purpose5/5

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

Opens with a specific verb+resource: 'Read the Monte Carlo schedule risk runs of a project.' That is unambiguous and distinguishes it from siblings like compute_risk_patterns, schedule_health_check or create_risk, which operate on risks rather than stored simulation runs.

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?

Gives concrete selection rules for the optional parameters ('runId reads one run by id instead', 'includeResult=true adds the whole stored result') and clarifies the boundary of the tool with 'runs are started from the project Risks tab or the REST API', i.e. this tool never triggers a run. No explicit comparison against sibling tools, so it stops short of 5.

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

All Onplana toolsInspect
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