Microsoft Project

Earned-value analysis against a stored baseline: BCWS, BCWP, ACWP, schedule and cost variance, SPI, CPI, EAC and TCPI, for the whole project and optionally per top-level WBS branch, plus the tasks with the worst slippage. This is the number a project board asks for and what feeds the S-curve. Says so plainly when no baseline is stored rather than returning zeros that look real.

Tie schedule tasks to the model elements they build, matching on a shared code (HRZ_COD_PRES, a keynote, a budget code). op='suggest' proposes the mapping from an element export and separates out anything that matched only on a code prefix for you to confirm; 'set' stores it; 'get' reads it back; 'clear' removes it. The mapping lives in a sidecar next to the schedule, so re-exporting the model never touches the planner's file.

Move data across the schedule/model boundary, in either direction. direction='model_to_schedule' turns measured quantities into duration proposals at a stated productivity rate — proposals only, which you then apply with tasks_write. direction='schedule_to_model' writes one row per element carrying its task's dates and progress: that file drives 4D animation in Navisworks, element parameters in Revit, and the progress dashboard in Power BI.

Manage working calendars: create them (optionally derived from another), delete them, set the working week and its hours (set_week), set exceptions for holidays, shutdowns or extra working days with their hours (set_exception), and choose the project calendar (set_project_calendar). Task and resource calendars are set with tasks_write and resources_write. Verified and dry-runnable exactly as tasks_write describes.

Read the dependency network. Almost always you want the subgraph around a few tasks rather than every link, so pass uids and a depth. drivingOnly returns just the chain that actually pushes the finish date, which is what you want when asking why the project ends when it does.

Add, remove, and change dependencies in one batch. Cycles are detected and refused before anything is applied, with the offending chain named in the rejection. Verified and dry-runnable exactly as tasks_write describes.

Export the schedule for another tool. 'mspdi' and 'mpx' write real schedule files; 'csv' and 'json' write a flat task table; 'pbip_dataset' writes the shaped dataset our Power BI report consumes — tasks, assignments, earned value and the S-curve — rather than a raw dump. Every schedule file written is read back and compared task by task — progress, actual dates, baseline, status date, outline and WBS, assignments (resource and units), task and project calendars, fixed and baseline cost, and each resource's max units, rate and calendar: 'notes' says 'Verified' when all of it survived and WARNING with what was lost when not (mpx keeps baseline dates without times, xer drops the baseline, pmxml drops in-progress percent; mspdi keeps everything). format='mpp' is written by Microsoft Project where it is installed and is all-or-nothing: it replaces the target only after reading back intact, and fails otherwise.

Diagnose what this server can do on this machine. Call it first in every session. Reports the active backend, runtime, whether Microsoft Project is installed AND whether its COM server actually starts, and a capability matrix the other tools honour. When something is wrong it returns the exact diagnosis and a repair path, not a stack trace. Pass deep=true to genuinely launch Microsoft Project instead of only reading its registration — slower and visible on screen, but the only way to know COM works.

Bring updates in from a CSV or JSON file — typically progress collected in the field. Runs plan-first: by default it matches rows to tasks by uid and returns the field-by-field diff without changing anything. Pass apply=true once you have read the plan, and the changes go through tasks_write so every one of them is verified by re-reading the model.

Summarise an open schedule: dates, counts, calendars, which baselines actually hold data, and the aliases of the custom fields. Read this before tasks_query — without the aliases nobody can tell what Text1 means in this particular schedule.

Open a schedule — or start a new one — and get a handle for every other tool. Reads .mpp, .mpt, .mpx, MSPDI .xml, Primavera .xer and .pmxml, Asta .pp and more, with no Microsoft Project needed. Returns a fingerprint of the file; later writes revalidate it and refuse if the file changed on disk in the meantime, so a stale handle can never overwrite somebody else's edits. Pass create=true to begin an empty schedule at that path instead of reading one.

Save or close an open schedule. Never saves on its own — closing with unsaved changes requires either saving first or passing discardChanges=true, so work is never silently lost. Every schedule file written is read back and compared task by task — progress, actual dates, baseline, status date: 'notes' says 'Verified' when all of it survived and WARNING with what was lost when not (mpx keeps baseline dates without times, xer drops the baseline, pmxml drops in-progress percent; mspdi keeps everything). format='mpp' is written by Microsoft Project where it is installed and is all-or-nothing: it replaces the target only after reading back intact, and fails otherwise.

Read resources, their assignments, and who is overbooked. Overallocation is computed day by day from the assignment spans — Microsoft Project's file format carries no such flag, so this is a real calculation rather than a field read.

Create, update, and delete resources, and assign or unassign them to tasks, in one batch. Verified and dry-runnable exactly as tasks_write describes.

Answer questions about the schedule without downloading it. Computes the critical path, the float distribution, the driving (longest) path, day-by-day resource overallocation, milestone status against deadlines and baseline, and the health of the dependency network. PMO control: status_report is the period report (planned vs earned %, SPI/CPI, earned-schedule SPI(t), EAC by three methods, TCPI, forecast finish, milestones at risk, trend of past cut-offs, health); lookahead is the short-interval (Last Planner) plan for the next weeks with each task's constraints and ready/constrained state, plus PPC of the last recorded commitment; change_log lists every rebaseline, budget load and committed edit with reason, approver and finish impact. Ask for only the aspects you need — each one is computed independently.

Build a new schedule — from the model, or from past projects. FROM THE MODEL: pass 'elements' as read from the Revit MCP (elementId, code, category, level, quantity, unit — no file needed) and get one task per trade per level, in construction sequence, from a start to a finish milestone with nothing left open-ended; durations are quantity over 'productivity' where a rate is given (by code, category or unit) and 'defaultDays' where not, flagged as assumed; the code goes into 'codeField' and every element is tied to its task, ready for bim_sync to write the 4D dates. FROM PAST PROJECTS: pass 'libraryPath' from schedule_learn. Each activity gets the duration its history says it takes, and the dependencies that usually surround it are recreated between the activities you asked for. Returns an open handle, so run schedule_qa on it before trusting it and adjust with tasks_write — this is a first draft grounded in what actually happened on past projects, not a finished programme.

Mine finished schedules for how long each kind of activity actually takes and what usually comes before and after it. Reads any number of .mpp, MSPDI or Primavera files, normalises task names so the same activity matches across projects and units, and reports each activity's duration distribution — median, 80th percentile, range — together with its typical predecessors and successors and the lag between them. Save the result and hand it to schedule_generate to build a new schedule from experience rather than from a blank page.

Run the DCMA 14-point schedule assessment plus Horizun's own rules, and report what is wrong with the schedule. This is the industry standard for judging whether a schedule can be run on: missing logic, leads and lags, hard constraints, high float and duration, negative float, invalid dates, unresourced work, missed baseline tasks, CPLI and BEI. Checks that genuinely cannot be evaluated (no baseline stored, no scheduling engine) are reported as not evaluated with the reason — never as a pass.

Work out what is late, what it is costing the finish date, and which changes to the logic would actually recover time. Lists the late work ordered by how much of the schedule is stuck behind it, then measures recovery levers — removing lag on the driving chain, overlapping finish-to-start hand-offs, compressing the longest critical tasks. Every option is applied to a throwaway copy, rescheduled, and reported with the finish date it genuinely produces; an option that recovers nothing says so rather than being offered as advice. Also returns replanReview: the tasks a planner should re-plan at this cut-off and why — not started when due, overdue, progressing slower than its elapsed time, drifting from its baseline, eating its float, started out of sequence — each with the figures behind it and the move to make. It proposes; the planner decides. Nothing is written to the open document.

Quantitative schedule risk analysis (Monte Carlo). Samples every remaining duration from a three-point range and re-runs the network logic (all four link types and lags) thousands of times, then reports the finish date at P10/P50/P80/P90, the probability of meeting a target and the baseline finish, the contingency needed for P80, and the risk drivers — how often each task is critical (criticality) and how strongly it moves the finish (sensitivity). Give per-task ranges from the team where you have them; the rest get the default spread.

Compare what-if scenarios without committing anything. Each scenario is a set of calendar, resource, task and dependency operations (the same ones the write tools take), applied to its own copy of the schedule, which is then scheduled. Returns, next to the schedule as it is: finish and its change in working days, total cost and its change, resource overallocation windows and peak load, critical task count, and anything a scenario asked for that was refused.

Recover the logic a schedule is missing by reading the order its own dates already state. A schedule whose work was laid out in the right order but never linked is a bar chart, not a network: nothing moves when anything slips, float reads as enormous, and any target date computed over it is arithmetic. This finds the repeating groups — apartments, floors, spans, wells, whatever the work repeats over — reads the order each one runs in, keeps only the orderings the repetitions agree on, and proposes the missing links. It never invents an order the dates do not state and never proposes a link where a path already exists. Defaults to proposing only; pass apply=true to write them, verified.

Test a schedule against a date you have been given. Reports whether the target is achievable, how many working days short it falls, the driving chain with the dates each task would have to hit, and every task the network does not actually hold in place — work with no predecessor or no successor, which never moves when its neighbours do and makes any target date arithmetic rather than a plan. Read-only.

Engine-level operations that take no per-task payload: save or clear a baseline, set the status date, reschedule incomplete work, level resources, or force a recalculation. Levelling and rescheduling are the two that do the most damage by accident, so they require a dry run to be seen first. Operations that need Microsoft Project's scheduling engine are refused outright on the MPXJ backend rather than approximated.

The workhorse read. Filter, sort, and page through tasks without pulling the whole schedule into context. Every task is identified by its stable uid — the id field is the row number and shifts when tasks are inserted, so never use it to address a task in a write. Defaults to a compact field set and 50 rows; ask for more only when you need it.

Create, update, delete and re-outline tasks in one batch. Progress (percentComplete, actual dates) is an ordinary update. Tasks are addressed by their stable uid — never by row id. Every change is re-read from the model after the write and only then counted as applied; anything the schedule refused comes back under 'rejected' with the reason and what the value actually became. Pass dryRun=true to run the whole batch against a throwaway copy and see the impact — how many tasks move, how far the finish date shifts, whether the critical path changes — without touching the open document.

Work or cost spread over time — the S-curve. Kept separate from the other reads because it is the expensive one: it refuses ranges that would generate an unreasonable number of buckets and tells you to coarsen the granularity instead of quietly returning tens of thousands of rows.