Read planning progress or a saved result
get_planning_calculationRead 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
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| section | No | 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. | status |
| dossier_id | Yes | ||
| result_path | No | 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. | |
| calculation_id | Yes |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| msg | Yes | ||
| code | Yes | ||
| data | Yes |