Which engines, asset classes and tax years this server covers for account-scope analysis, with each engine's limitations

What it needs, and why

This command takes no arguments: it reports what the server covers. Which engines, asset classes and tax years this server covers for account-scope analysis, with each engine's limitations. Harvesting, exact optimization and rebalancing are separate engines making separate claims. Reading the registry before promising anything is the difference between a refusal and a plausible wrong answer.

Requests it answers

• “What does this server cover, and what does it decline?”
• “Which engine answered, and what does it not claim?”

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 portfolio

The 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.

Also exposed by taxagent-household, which describes it as: What household analysis covers, and which engine makes which claim. A joint optimizer is available and proves optimality where its search exhausts; the coordinator is sequential, order-dependent and never optimal.

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.