Skip to main content
Glama

Read planning progress or a saved result

get_planning_calculation
Read-onlyIdempotent

Read status (default), fixed input (input), lightweight choices (list), user-facing details (reading), or raw details (result). Saved metadata includes calculation_scope, continuation_of and route_summary. Use a ready route_summary covering ordinary and forecast 189 routes to distinguish available diagrams from usable conditional PR dates; never infer no date from pending/failed work, failed forecast, an unavailable decision or unread data. Show available routes first; partial scope is not exhaustive. Status queries wait up to ten seconds of waiting time for the same task and return actual progress with retry_after_seconds; network time is separate. While pending, continue with the same ID and honour retry_after_seconds; do not add arbitrary delays or stop merely after several polls. An interrupted query does not require a new calculation. Stop polling at succeeded/failed. Success is calculation completion, not delivery of a requested plan. A status-only question still requires reading current status; never report an unread successful calculation as unfinished. A progress follow-up continues an undelivered plan unless the user explicitly asks for status only, pauses or cancels. If a real host limit or persistent failure prevents waiting, verify an authorized supported follow-up or explicitly state none was scheduled; never promise an unregistered later check. After succeeded, start list at result_path="" with default limit=100 to locate candidates and scope. Unknown PR dates and partial search still require showing available preparation plans. Explain successful ordinary results even if forecast failed, preserving its error. A directions-only question may end with a list overview. For planning, next steps or a substantive result explanation, choose the most relevant 1–2 candidates from user facts/preferences and read the necessary conditions, preparations, dependencies, sources, time and costs before the first substantive reply, without asking permission to inspect them. This explanatory choice neither saves goals nor authorizes recalculation. Explain common preparation once, then distinguish occupation choices from visa endpoints; retain separate ordinary/forecast references, conditions and coverage without adding their route counts. Keep known facts, unresolved facts and future conditions distinct. When the user names a route or condition, directly use its returned reading_ref section/path and relevant reading_sections without asking permission again. When returned condition_sources/sources references explicitly identify the selected route’s conditions, read those details first to obtain condition text and sources together, then supplement reading only for missing fields. Reuse already-read corresponding condition fields across reading/result; matching paths alone do not establish equivalence. Keep the default page size for condition/source objects; small limits suit rich route collections. Follow unread references/pages needed for the claim. Once source text, URL and applicability limits suffice, stop without chasing optional display/summary copies; read display when it holds necessary evidence or limits absent from the source text. A scalar result_value_too_large (413) cannot be fixed by lowering limit; if necessary evidence remains unread, state the limitation and answer only from what was read. Before making a detailed claim, read its supporting sources and the relevant conditions/dependencies through their remaining pages and references; retain source limitations. Read preparations, time or cost when they support the requested answer, without opening every section or route. Continue next_cursor at the same section/path/dossier/calculation; clear cursor when switching section or path; cursors do not cross projections. A small limit suits rich route collections, not the root. result_list and result_reading supply their respective field meanings. A complete list value does not include the full explanation; read selected details before explaining the route. Preserve scope_gaps explaining directions deferred for unresolved preferences separately from conditions, unknown scores/dates/costs, sources and partial search; job completion is not visa approval. Raw detail is optional. GET never computes. No VIP results. Requires the authenticated One U Education account and declared planning scope; credentials and user identity are never tool arguments.

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": {
      "dossier_id": "<dossier_id>",
      "calculation_id": "<calculation_id>"
    },
    "name": "get_planning_calculation"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
cursorNo
sectionNoUse list to give a useful overview of the returned choices and scope first, without fetching all detail. When the user names a route or condition, directly read the relevant reading_ref/reading_sections without asking permission again. result_list describes the list projection; result_reading describes expanded detail. result is raw detail, input is the fixed calculation input.status
dossier_idYes
result_pathNoEmpty string starts the overview. Copy each returned reading_ref or reading_sections reference section and path into section and result_path; reading_sections may target reading or result. detail_path belongs to raw result. Reset cursor when changing section or path. An inline entry is complete only within its selected projection.
calculation_idYes

Output Schema

NameRequiredDescriptionDefault
msgYes
codeYes
dataYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / $defs / __schema1 / enum
      Previous value: -[
      -  "status",
      -  "input",
      -  "reading",
      -  "result"
      -]New value: +[
      +  "status",
      +  "input",
      +  "list",
      +  "reading",
      +  "result"
      +]
    • changedInput schema / properties / result_path / description
      Previous value: -"Empty string starts the overview. An inline entry already contains its complete value; follow reference paths only when their content is needed."New value: +"Empty string starts the overview. Copy each returned reading_ref or reading_sections reference section and path into section and result_path; reading_sections may target reading or result. detail_path belongs to raw result. Reset cursor when changing section or path. An inline entry is complete only within its selected projection."
    • changedInput schema / properties / section / description
      Previous value: -"Use reading for user explanations; its expanded logical content is described by the result_reading Schema. result is raw detail, input is the fixed calculation input."New value: +"Use list to give a useful overview of the returned choices and scope first, without fetching all detail. When the user names a route or condition, directly read the relevant reading_ref/reading_sections without asking permission again. result_list describes the list projection; result_reading describes expanded detail. result is raw detail, input is the fixed calculation input."
  2. Added

TDQS

A4.3/5.0
Behavior5/5

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

With readOnly, idempotent and non-destructive annotations already covering safety, the description adds substantial operational context: status polling waits up to ten seconds, returns retry_after_seconds and treats network time separately; interrupted queries do not require a new calculation; success is calculation completion rather than delivery; 413 cannot be fixed by lowering limit; cursors do not cross projections; GET never computes and no VIP results are returned. These are exactly the behavioral traits annotations do not convey.

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

Conciseness2/5

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

The content is front-loaded with the modes, but it is delivered as a single dense paragraph of roughly a thousand words with no headings or bullet structure. Many sentences are operationally necessary, yet the density and repeated treatment of polling and reading references make the description hard to scan, so it is not concise.

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?

Given the high domain complexity, 6 parameters, 33% schema coverage and an existing output schema, the description covers the full lifecycle: selecting a section, polling status, reading references, handling cursors and limits, preserving scope gaps, and error cases. Nothing an agent needs in order to invoke it correctly appears to be missing.

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 only 33%, but the description compensates by explaining section modes, result_path='' to start the overview, copying reading_ref/reading_sections into section and result_path, continuing next_cursor at the same section/path/dossier/calculation, and using small limits for rich route collections. It does not explicitly define dossier_id or calculation_id, though their role as identifiers is evident from context.

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 opens by enumerating the five read projections (status, input, list, reading, result) and names the resource as a planning calculation, so the verb and object are unmistakable. It does not explicitly contrast with sibling tools such as get_planning_dossier or list_planning_calculations, so sibling differentiation is left implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides extensive when-to-use guidance: e.g., 'Use a ready route_summary...' 'While pending, continue with the same ID...' 'Stop polling at succeeded/failed' and 'For planning, next steps or a substantive result explanation, choose the most relevant 1–2 candidates...'. It also specifies when not to infer missing dates and when a directions-only question may end with a list overview, making alternatives among sections explicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources