Status of a run
One command on the Portfolio lots and harvesting server, callable over MCP as get_run_status. Every result carries the method it used, the rule pack it was pinned to, what is still missing and whether coverage was complete, for a licensed professional to review.
What it needs, and why
Every input is checked before anything is calculated. run_id is required; the rest refine the answer.
| Input | What it asks for | Why it matters | If you omit it |
|---|---|---|---|
run_id | run_id | A run is addressed by its id. Transport success is not workflow completion. | required |
Requests it answers
- “Did that tax analysis actually finish?”
- “Is a completed run a complete answer?”
An agent with these skills loaded picks the command from phrasing like that, asks for whatever input is missing, and reports the figures with the method that produced them.
Run it
TAXAGENT_TENANT_ID=... TAXAGENT_PRINCIPAL_ID=... TAXAGENT_ACCOUNTS=... scripts/mcp_server.sh --server portfolioThe same command is exposed by taxagent-portfolio, so Claude, Claude Code, Codex, Cursor and any other MCP client can call it directly. Analysis only. No tool in this server places orders, modifies custodian records or files returns. Every result is scoped to the accounts this principal is entitled to read; an account named in an argument is a request, not a grant. Unknown basis blocks a lot rather than defaulting to zero.
Limits it inherits from taxagent-portfolio
- Greedy selection; no optimality claim.
- No multi-period or risk-aware objective.
- Optimal means optimal over the lots, prices and constraints supplied, for the stated objective: reach the cash target, realize as little gain as possible, use as few trades as possible. It is not a statement about what the account should do.
- Risk, tracking error, a client's view on a position and the reason a lot was bought are outside the model entirely.
- Beyond 40 budget-consuming lots the search is not exhausted. The status degrades to feasible and a gap is reported; optimality is never claimed from a truncated search.
- Account scope only. Running it once per account is not a household optimum.
- Drift is the sum of absolute differences between current and target weight. The engine never sells more of a security than its overweight, so with chunky lots it under-trades rather than overshooting, and residual drift is expected and reported.
- Buys are allocated across underweight securities in proportion to their shortfall. A purchase has no tax consequence, so there is nothing to optimise about which lot it becomes.
- A buy is withheld when the security was sold at a loss inside the wash-sale window, which leaves that drift open until the window closes.
- Requires advisor-supplied target weights. Inferring a target from the current holdings would make the portfolio its own benchmark.
- Account scope only, and no view on transaction costs, market impact, tracking error or which account should hold which exposure.
The server, its other 8 commands and what it deliberately leaves alone are on the Portfolio lots and harvesting page.