com.meta-council/decision-intelligence

Tools

• account_export

  Export this account's own data across every table the account owns, as the same JSON envelope the REST route returns. The set of tables served is derived from the same ownership reflection that decides what an account deletion removes, so a table the account can destroy is a table it can also read. Credentials never appear: columns held encrypted at rest are withheld unless recorded as the account's own content, and password hashes, reset and verification tokens, and API key hashes are withheld by name. Some tables are deliberately excluded -- see docs/ACCOUNT_DATA_EXPORT.md, and note that the coverage block on every response lists exactly which models are served and which are excluded with their reasons. Artifacts are described by their metadata rows rather than inlined. Bounded rather than streamed: each model reports truncated and the envelope reports complete, so narrow to one model and raise rows_per_model rather than re-reading everything. This is a data export, not an erasure request and not a claim of regulatory compliance. Requires authentication and the account:export scope.

  deep
• add_comparison_runs

  Append finished runs you own to a set. All or nothing: a run that is unknown, not yours, still running, or already a member refuses the whole call and leaves the set exactly as it was. Requires comparisons:write.

  shallow
• add_invoice_line_item

  Add a billable line item to a draft or sent invoice; totals are recomputed automatically. Blocked once paid/void. invoice_id is required.

  shallow
• add_outreach_lead

  Add a single lead to the authenticated user's outreach book. Returns the new lead id. Provenance is stamped source="agent" server-side. Does not send any email. Requires authentication.

  shallow
• advance_workflow

  Advance a workflow past a human checkpoint — approve or reject the paused step so the pipeline continues. Use the session id from run_workflow / get_workflow_session. Requires authentication.

  shallow
• approve_consulting_deliverable

  Approve one submitted internal deliverable and record approver evidence. Requires consulting:approve and never publishes or sends it.

  shallow
• approve_consulting_document_revision

  Approve and lock one exact proposal/SOW revision. Requires the separate consulting:approve scope and never publishes or shares it.

  shallow
• approve_content_asset

  Approve a submitted owned revision and attest to its exact content hash. Requires marketing:approve, separate from draft authority.

  shallow
• approve_outreach_draft

  Record exact draft approval bound to recipient, campaign, subject and body. Supply the reviewed draft_sha256 as expected_draft_sha256; changed input refuses. This does not create consent, enroll or send. Requires outreach:write.

  shallow
• archive_saved_view

  Retire one of YOUR OWN saved views without destroying it: it drops out of the default listing and execute_saved_view refuses it, but its definition is kept and restore_saved_view brings it back unchanged. Prefer this over delete_saved_view. Idempotent -- archiving twice keeps the original archive time. Archiving is your own working state and does not hide the view from a team it is shared with. Requires authentication and the tickets:write scope.

  shallow
• archive_ticket_provider_fields

  Archive an owned provider field link using its exact revision. Retains immutable captures and a revision tombstone; no provider call or remote unlink. Exact request retries recover the original result. Requires tickets:write.

  shallow
• ask_legal

  Request fixed legacy Themis source/citation records and attach a proposed Laws & Regulations agent/source/synthesis plan whose routes are planned_not_run. Check the law uses fixed legacy provider-record retrieval, but returned records do not prove exact citation identity, relevance, authority, or corpus coverage. Generated research requires authentication, exact THEMIS_NEUTRAL_SCHEMA_VERSION=themis_neutral_research/v1, the operator gate, a verified authenticated corpus manifest, and an atomic spend reservation. The manifest verifier is not available yet, so generated mode remains disabled. Provider assertions/gaps are enum codes linked to evidence whose quote-fidelity state is provider-reported and rendered with fixed server text; any legacy verdict or answer prose is withheld. Returns legal_evidence_graph/v1. Automated research only, not legal advice. Requires legal:run.

  shallow
• assign_leads_to_campaign

  Assign one or more of the user's existing leads to one of the user's campaigns (both must be owned by the caller). Returns how many were assigned. Idempotent. Requires authentication.

  shallow
• audit_export

  Export this workspace's own agent-action audit trail as structured events, oldest first, for loading into a SIEM. Each event carries what triggered the action, which identity authorized it, which resource was touched, the outcome, and the error state. Metadata only -- no prompt text, document content, tool arguments, or model output is ever returned. Filter by date range and event action; page forward with the cursor each response returns. Covers a documented subset of platform activity rather than every action: see docs/WORKSPACE_AUDIT_EXPORT.md, and note that the coverage block on every response lists exactly which actions are exportable and which are not. Requires authentication and the audit:read scope.

  shallow
• book_meeting

  Commit the exact owner-confirmed create preview using both independent scheduling grants. This can notify the recipient, including cancellation. Reuse the same preview, hash and confirmation reference after uncertainty. Missing private process custody permits receipt recovery but cannot authorize a new dispatch; no manage secret is reconstructed.

  shallow
• browse_ticket_integration_import

  Read one bounded page of importable items live from a saved GitHub, GitLab or Asana connection. GitHub: open issues, oldest first, 20 per page; page 1 to 50 (GitHub only). GitLab and Asana: the first 20 items only. Not a snapshot or complete inventory. Read-only provider requests; never writes to the provider or creates tickets. Requires integrations:read and tickets:read.

  shallow
• campaign_pipeline_stats

  Pipeline-stage breakdown for one outreach campaign — total / sent / active / won / lost, reply rate, and per-stage lead counts. Requires authentication.

  shallow
• cancel_booking

  Commit the exact owner-confirmed cancel preview using both independent scheduling grants. This can notify the recipient, including cancellation. Reuse the same preview, hash and confirmation reference after uncertainty. Missing private process custody permits receipt recovery but cannot authorize a new dispatch; no manage secret is reconstructed.

  shallow
• capture_feature_forecast

  Explicitly save an immutable owner-private delivery scenario and minimal replay inputs for one epic's current descendants, including archives. Default window is eight UTC weeks. Reuse the same owner-wide request_id and exact arguments after an uncertain response; retries return the original capture even after source deletion. Missing history remains unavailable. No schedules, notifications or provider work.

  shallow
• check_ticket_provider_fields

  Explicitly read five native fields for an existing owned link revision. Requires integrations:read and tickets:write. Reserve before I/O; retry exact request_id/arguments to recover its original result without another provider call. Changed link or credential refuses. Unsupported/missing fields and noncomparable native formats stay unknown. No remote writes or automatic reconciliation.

  shallow
• check_ticket_provider_status

  Read the linked Jira/Linear issue status and retain an owner/link/configuration-bound observation. Requires explicit integrations:read and tickets:write. No issue creation, status transition, or automatic recovery of uncertain effects. Inspect the observation and current evidence, then use the original effect ID for explicit reconciliation if needed. Each deliberate check records new evidence; unavailable or changed bindings remain unknown.

  shallow
• commit_ticket_integration_import

  Import previewed items as new top-level backlog tasks. Re-reads every item; if anything changed since the preview it refuses and creates nothing. Tickets, links and a content-free receipt commit together or not at all. Never writes to the provider. Use a new request_id per import; repeating one with the same provider, connection and selection returns the original receipt (replayed true) without importing again. If an outcome is unconfirmed, inspect get_ticket_integration_import_receipt before another import. Requires integrations:write and tickets:write.

  shallow
• compare_feature_forecasts

  Replay and compare two owned saved delivery scenarios with the same cohort and window. Separately reports elapsed capture time, expected-date drift, remaining work, rate and exact modeled duration change. Date drift alone is not worsening throughput. Missing history or changed cohorts return noncomparable; no attention reason or notification is created.

  shallow
• compare_scope_baseline

  Compare an owned baseline with current scope, estimates and completion. Deleted/moved tickets remain visible; unknown estimates are not zero. Requires tickets:read.

  shallow
• complete_sales_task

  Mark one of the caller's sales tasks/activities done (or reopen it with done=false). Stamps or clears the completion time; activity_id is required.

  shallow
• confirm_ticket_integration_create

  Settle one uncertain create effect by reading the remote item you name in the effect’s own connection: GitHub issue_number, GitLab issue_iid or Asana task_gid, exactly one, for the effect’s provider. Bounded read-only provider requests. Only when that item carries the effect’s correlation marker does one local commit record the link and an immutable settlement; otherwise nothing is recorded. Never writes to the provider, retries, recreates or replays the effect. Refused until the deploy-owned settlement activation (graph v3). An effect left cancelled with attempt_count 1 cannot be settled. If an outcome is unconfirmed, read list_ticket_integration_effects_v2 before another action. Requires integrations:write and tickets:write.

  shallow
• confirm_ticket_integration_status

  Settle one uncertain GitHub or GitLab status effect by re-reading the ticket’s linked issue. Bounded read-only provider requests. Only when the issue shows the status the effect wrote does one local commit refresh the link’s observed status and record an immutable settlement; otherwise nothing is recorded. Asana has no status effects. Never writes to the provider, retries or replays the effect. Refused until the deploy-owned settlement activation (graph v3). If an outcome is unconfirmed, read list_ticket_integration_effects_v2 before another action. Requires integrations:write and tickets:write.

  shallow
• convert_deal_to_invoice

  Create a draft invoice from one of the caller's deals: one line item for the deal's amount, client_name defaulted from the deal's company/title. deal_id is required.

  shallow
• convert_lead_to_deal

  Convert an owned outreach lead into a deal and advance the lead into the deal stage of the funnel (never downgrading an already-closed lead). Optional deal fields mirror create_deal; lead_id is required.

  shallow
• create_accounting_run

  Analyze supported textual accounting records with the pinned deterministic Writeoff engine and create a private, encrypted audit run owned by the caller. Accepted filenames end in .txt, .md, .text, .eml, .csv, .ofx, .qfx, or .qif. Returns estimates for review only: it does not file taxes, move money, or send data to an external accounting service. Send prepared rows, not raw document text. Pasting the output of a PDF-to-text converter does not fail loudly. Read verbatim as .txt, .text or .md, the whole paste collapses to exactly ONE entry, and that entry's figure can be a real number from the page that is not a charge at all: a statement with no footer total books its running BALANCE as spend. Stripping the page headers and the balance column does not change that; a genuinely empty paste raises instead. Convert each document into canonical CSV first: a Date,Description,Amount header, then one row per economic event. The Description column carrying the merchant name alone is the cleanest form, and prose is not merely untidy -- it CHANGES the answer. The matcher runs over the whole description against a vocabulary that holds ordinary words as well as vendor names: paper, printer, ink, notebook, legal, consulting, subscription, hosting and domain each classify alone with no vendor present, and contact lens or reading glasses classify as a MEDICAL deduction. A memo line saying what was bought can therefore create a deduction the vendor name alone would not. Send the merchant, not a description of the purchase. Not every phrase matches -- weekly grocery run, haircut and banana all stay unclassified -- but plain English is not inert. Classification is separately gated by context_text, but that gate is PARTIAL, not an off switch. Leaving it empty suppresses only the rules that need a business to exist: business, meals, vehicle and home-office. The personal rules stay live whatever you send -- a bare contact lens still classifies with context_text empty, under the category name fsa_hsa rather than anything called medical, and donation and tuition classify the same way. An empty context is NOT a way to stop deductions being proposed. The business gate is a bare substring test, not a reading of what you wrote: it opens on a keyword anywhere in the text, so I do not own a business and This is a personal return, not a business each switch the business rules ON rather than off. Negation is not detected. Suppress those rules with an EMPTY context, never with a denial. Booking is independent of all of it -- a row books its amount whether or not it classifies, and classification decides only whether the row becomes a deduction candidate. State the direction of every row. A .csv is routed as a statement, so each row has to say whether money went out or came in. Send exactly Date,Description,Amount,Type -- the amount column named Amount, and a Type of Purchase for money out or Refund for money in. Separate the fields with COMMAS. The delimiter is sniffed from the header row, and a semicolon additionally switches the amount parser to the European convention where the comma is the decimal point and the dot is a thousands separator. In a semicolon-delimited file an ordinary -20.00 is therefore read as 2000.00 and -1234.56 as 123456.00 -- silently, with no error, a hundred times the real figure. Tab and pipe keep the dot decimal. Send only these four columns, each once. Order among the four does not matter -- all 24 arrangements of Date,Description,Amount,Type measured identical -- but each once is load-bearing, because a repeated header resolves to the LAST copy. A second Amount REPLACES the figure, so it can under-book as easily as over-book; a second Type can make a file of refunds BOOK as spend just as easily as it can drop the whole file, and on three rows written Type=Refund,Purchase the last copy wins and all three book; and a second Date silently rewrites every date while the row count and the total stay exactly right. A literal Amount now protects the figures from same-direction ancillary debit- or credit-looking columns. A literal Amount beats one or more same-direction ancillary columns in either order, whether those cells are populated or blank. Those ancillary values are not silently substituted. Opposite-direction ancillary columns together form a complete pair and fail closed beside Amount. Schema arbitration happens before row direction; Type cannot rescue an ambiguous schema. After arbitration selects one money representation, row direction uses a recognized Type first. Only when Type is absent or unrecognized does a trailing CR or DR marker decide. Only when both are absent does the selected money heading or sign decide. Thus Purchase and Refund outrank a conflicting marker on an otherwise unambiguous schema; notably, Payment is unrecognized and preserves the fallback. Conflicting money representations fail closed instead of being chosen by header order. Distinct equal-ranked amount aliases, multiple equally ranked same-direction money headers without a literal Amount, an amount alias beside a separate debit/credit representation, a literal Amount beside a complete pair, and a third amount candidate beside a pair each produce a named ambiguous-money error. A complete Debit/Credit pair remains supported, but a row with both pair cells nonzero fails closed. On a row with neither recognized Type nor CR/DR marker, a negative debit is a reversal and remains credit, while a negative credit is never promoted to spend. Within one role vocabulary, exact matches still beat partial matches. Column roles remain isolated. Description prefers an ordinary non-role heading. If none exists, exactly one releasable semantic-directional heading such as Charge Description or Payment Memo may serve, but only when an independent money representation survives without it. Outside that semantic-directional exception, suppressed lower-tier money, date and type candidates remain reserved and cannot become Description merely because a stronger sibling won their original role. Structural composites such as Amount Details, Transaction Type Description and Debit Details, or multiple competing semantic candidates, cannot serve as Description; when only those remain, the file fails closed rather than poaching merchant text. Identical duplicate headers remain a separate hazard: DictReader uses the LAST copy. A second Amount REPLACES the figure, a second Type can make refunds book as spend or purchases drop, and a second Date silently rewrites every date. That residual duplicate-heading behavior is not an ACC-045 fix, so send the four canonical columns once each. Type is matched against a fixed vocabulary, not read as free text. purchase, debit, charge, withdrawal and dr mean money out; refund, credit, deposit, return and cr mean money in. All eight spelled-out words resolve in the plural as well, but the two abbreviations do not: drs and crs are unrecognised and fall through to the amount CELL, so a crs row written negative books as SPEND, not as money in. Anything else -- notably Payment, money in on a card but out on a checking account -- counts as unstated, and the direction then falls to the amount CELL rather than to the sign alone. Write the amount as a plain signed number, with nothing else in the cell. A trailing DR or CR and accounting parentheses are not decoration, and what they do depends on the column holding them and on the parser the CONTENT selected -- NOT on the file suffix. Two separate things happen to such a cell, and BOTH are confined to the statement path -- the fan-out described under Routing below. First, in every statement format and every column, the figure is given a sign: parentheses negate, DR negates, and CR does nothing at all. DR is a SIGN; CR is only a label. On the single-receipt path no marker is a sign at all: a total written 20.00 books 20.00, and that same total written 20.00 DR, (20.00) or 20.00 CR books 0.00 -- there the marker makes the amount UNREADABLE rather than negative. Second, when the content parses as CSV and schema arbitration has selected one money representation, row direction reads recognized Type first and then any marker on the selected money cell. A marker never overrides recognized Type; with Type absent or unrecognized it outranks the selected heading or sign. On a bare Date,Description,Amount file, 20.00 DR and (20.00) are both money OUT, and even -20.00 CR is money IN. A recognized Purchase or Refund still outranks either marker. A cell carrying no marker falls back to the SIGN, under the bank convention where money out is NEGATIVE, so a plain POSITIVE amount reads as money coming in and is dropped as non-deductible. On three rows totalling 137.19: written plain and positive they record nothing, and those same positives written 20.00 DR or (20.00) record all three. This CSV marker reading applies to the selected single money column or the selected nonzero cell of a complete pair. With Type absent or unrecognized, 20.00 CR is credit and 20.00 DR is debit under Amount, Charges or Payments. With neither recognized Type nor marker, heading/sign fallback remains: positive Charges is spend, negative Charges is a reversal, and a lone Payments column is credit. Beside literal Amount, even a blank Payments column is ancillary and cannot void honest figures. A money column whose name is in NEITHER vocabulary is a third way to record nothing. Purchases, Spend, Cost and Total were each measured doing it -- they are examples, not a list to check yours against -- and a file whose only figures sit under such a name returns zero rows at BOTH signs, with no error. Recognition is by name against a closed list, so the remedy is not a clearer word of your own but the four columns named at the top of this contract. Native OFX and QIF content behaves like a plain AMOUNT column and NOT like a money-out column, on all six markers, under .ofx, .qfx and .qif alike: the sign left by the first step decides, so -20.00 CR is money OUT, and so is (20.00 CR); 20.00 DR is money OUT because DR negated it; and a plain positive 20.00 is money IN and dropped. TRNTYPE is never consulted -- DEBIT with a positive TRNAMT still drops. Because the parser follows the CONTENT, a .qfx holding canonical CSV runs the CSV rules above instead, markers and all. Dropped rows are silent, and nothing in the result marks a row as dropped. A run does fail when it analyzed nothing at all across the whole submission, and separately on transport, input and engine errors -- but no failure mode reports a PARTIAL loss. If even one row anywhere survives, the run completes and the rest vanish with no notice, so a completed run is NOT evidence every row was read. A three-row file with one negative amount and two positive ones returns one row, no error, and a total indistinguishable from an honest one. The one loss that IS named is a document that contributed nothing at all. When a submitted file appears in no catalog channel -- no item, no unclassified row, no notice, no error -- and it held at least two non-empty lines, catalog.notices carries a source_left_no_trace entry naming that file. That covers whole-file loss: a statement whose rows use a different delimiter than its header, and a body of unreadable bytes under a valid header, both otherwise return the same empty success as a file that genuinely held nothing. A header-only export stays silent by design -- it has no body to lose. This does not narrow the PARTIAL case above: a file that recorded even one row counts as read, so rows dropped beside it remain silent. Routing is by filename suffix, not by content, against a CLOSED allowlist -- and the allowlist is assembled from two constants that DISAGREE. SUPPORTED_SUFFIXES in web/accounting_engine.py admits eight: .csv, .ofx, .qfx, .qif, .txt, .text, .md and .eml. STATEMENT_SUFFIXES in writeoff/batch.py names the five that fan out into one row per line, and one of those five is .xlsx, which the engine refuses before any parser sees it. What fans out is the INTERSECTION -- .csv, .ofx, .qfx and .qif. The other four -- .txt, .text, .md and .eml -- are read as a single receipt. Of those, .txt, .text and .md are read VERBATIM and behave identically to each other; .eml is NOT one of them. An .eml is parsed as an email FIRST -- headers dropped, transfer-encoding decoded, an HTML body flattened into lines at its block tags -- so every rule below applies to THOSE lines and not to the file's, and the same bytes can book a different figure, name a different merchant, or record a load error and contribute no entry at all. Statement rows sent that way collapse to ONE entry, and what that entry books turns on the PRICE pattern below: a file that LOADS and in which NO line ends in a price books 0.00, silently and with no error. An .eml with no extractable body -- an attachment-only mail -- never reaches that stage: it contributes NO entry and records an EmailIngestError in the run's errors, while still being listed among its sources. Its merchant is NOT the file's first line: it is the first line that neither ends in a price nor is a bare date, so a file led by a CSV header books that header text as the merchant, and a file whose every line ends in a PRICE books an EMPTY merchant. Ending in a bare number is not enough: a Closing balance 900 line is itself booked as the merchant. The winning figure is chosen by matching against the WHOLE lower-cased LINE, description included, so a purchase from TOTAL WINE AND MORE reads as the file's total. A label is only ever read on a line that ENDS in a price, and a price means EXACTLY TWO DECIMAL PLACES: a whole-dollar Total 137 is not a price, and neither are 137.1, 137.190 or a trailing 137. -- none of their labels are ever read. The pattern is anchored at the END only, so what stands in FRONT of the figure is unrestricted: Total USD 137.19 and even Total about 137.19 both read as totals, and a leading dollar sign is merely one case of that. After the digits it admits an optional minus and at MOST ONE trailing letter, and those letters are UPPERCASE ONLY -- T, N, X, F, E or an asterisk, while a lowercase t, n, x, f or e leaves the line with no price at all. So a line reading Total 137.19 USD, Total 137.19 (USD) or Total 137.19 EA carries no price at all, its label is never read, and the file falls through to its largest amount -- and a payable line behaves the same way, so an Amount Due 137.19 USD is not a payable line either. That property, not the marker, is why a Total 137.19 CR is not read as a total: CR is two letters, so the line has no price. Otherwise any line containing total is a total line and the LAST one wins -- not the first, not the largest -- so that wine row REPLACES an honest footer standing above it. Excluded are subtotal and sub total, though the near-miss sub-total is not excluded and does win, and any total line also holding saving, save, discount, coupon or reward as a bare substring; that is the entire exclusion list in the pinned dependency today. Those exclusions are the dangerous half: an excluded line is read as NO total rather than as a smaller one, and the search moves past it to the payable stage below, with no zero total present, and only then to the largest amount. Rows of 4812.00 and 12.34 under a Total Rewards Earned of 42.10 book 4812.00 -- a hundredfold over-book off a line the file itself labels a total. Give that same file an Amount Due of 42.10 and the payable stage rescues it. A ZERO is not an exclusion and does not chain that way. A total line reading 0.00 WINS its stage and sets the total to zero, and a zero total SUPPRESSES the payable stage, so the file drops to its LARGEST amount in EITHER order: an Amount Due of 42.10 standing above or below a Total of 0.00 does not rescue it. A paid-in-full invoice reading Total Due 0.00 books its largest line item. Last-wins covers zeros too, so a Total of 0.00 below a real Total of 42.10 WIPES it. The payable stage does not behave that way -- it takes the last payable line whose figure is NON-ZERO, so a trailing Amount Due of 0.00 leaves an earlier Amount Due of 42.10 standing. With no total line surviving, a line reading amount due, balance due, amount payable or please pay is used instead, last-wins again and only when its figure is non-zero. Those four are matched as LITERAL text, so the doubled-space spellings Amount Due and Balance Due, and likewise Amount-Due and AmountDue, are NOT payable lines at all; a file whose only payable label is spelled one of those ways skips to its LARGEST amount, which is the direction that over-books. A trailing colon in Amount Due: still matches. Failing every stage, the largest amount anywhere in the file. One hazard, though, is NOT confined to that last stage. The price read is END-anchored on the LINE, not on a column, so it reaches back across commas and swallows text belonging to the field BEFORE it. It takes the line's final cents pair and walks LEFT across each comma-separated group of EXACTLY three digits, then swallows up to three trailing digits of whatever text precedes the first such comma -- an amount's cents, a check or invoice number, a card last-4, a units or store-number column; money or not, decimal point or not. A group of one, two, or four-or-more digits terminates the walk. So a row of -12.34,887.66 yields 34,887.66 -- a figure that appears in NO cell of the document, even though those characters occur across the comma between two cells in the raw text. That splicing happens while the price is being READ, which is before any label is tested, so a spliced figure is what a total line or a payable line CARRIES INTO its own stage: a footer reading Total,-60.34,887.66 books 34,887.66 rather than 60.34, and an Amount Due,-12.34,887.66 books 34,887.66 the same way. Holding an explicit Total line is therefore NOT a way out of this. The field on the LEFT need not be money and need not carry a decimal point: a check register whose amount is the LAST column books 140,732.19 from a row reading 2029-06-02,8140,732.19, and an Amount Due,INV 4522,887.66 books 522,887.66. There is no ceiling on the RIGHT either -- -31.20 beside 412,880.55 books 20,412,880.55, because 412 and 880 are each groups of exactly three. What stops the walk is GROUP WIDTH alone, so a right-hand 1000.00, 4,887.66 or 12,345.67 is read whole, and the total line then books THAT figure rather than its own. A spliced figure is usually in no cell of the document, but not always: when the digits swallowed are all ZEROS -- an amount's 00 cents, or a round 1000 -- it lands exactly on the right-hand figure, so agreeing with a real cell is not evidence of a clean read. No error is raised in any of these cases. Send that file as .csv instead, where the splice does not occur. Rows of 200.00 and 12.34 under a Total of 137.19 book 137.19; delete that total line and the same file books 200.00. The winning line's own minus sign is DISCARDED at either stage, so a Total of -137.19 and an Amount Due of -137.19 both book 137.19. The entry books 0.00 whenever NO line in the file ends in a price, and a DR, CR or parenthesis marker on every amount is only ONE way to reach that state: whole-dollar amounts, a trailing currency code and a trailing period each book 0.00 with no marker anywhere in the file. Where a marker IS the cause, leaving the winning line unmarked makes it book in full, whether the winner is a total or a payable line. Every rule in this paragraph is measured on the LINES the loader hands the parser: for .txt, .text and .md those are the file's own lines, and for .eml they are the extracted body's. Anything outside the eight is REFUSED outright with an unsupported-file-type error rather than silently mis-read, so .pdf and .xlsx never reach the parser. Because the second set lives in a pinned dependency, treat the four as measured today, not as a promise. That split is by suffix; WITHIN those four the parser is chosen by CONTENT, so a .qfx holding canonical CSV runs the CSV column contract above in full. One row per economic event. An invoice and the receipt that pays it are one event; submit both and BOTH are counted, doubling the deduction. Same-day duplicates raise a possible_duplicate notice, but rows dated days apart -- the usual invoice-to-receipt gap -- raise nothing at all, so the total is silently twice the truth. Collapse duplicates before submitting. Scope each run to one entity and one tax year, and name it that way -- totals spanning entities or years match no filing. Book each event on the date money moved (cash basis) unless the entity files accrual, and never mix bases in one run. Submit runs one at a time: one ingest is active per owner at a time. The returned total counts classified spend only. Charges whose merchant matches no deterministic rule are excluded from it, so do not present it as total spend. Use preview_accounting_ticket_sync to turn those residuals into reviewable work. Never submit a figure you cannot find verbatim in the source document, and never adjust a merchant name to make a row classify: Description is what the engine matches on, so renaming an unrecognised vendor to a recognised one raises the deduction while every figure stays verbatim. An unclassified row is the engine declining to assert a rule it does not have. Leave it, and report the count.

  shallow
• create_comparison_artifact

  Record one durable comparison between a member run and a candidate run you own, usually one a comparison just created. Requires comparisons:write.

  shallow
• create_comparison_set

  Create an empty owned collection of finished runs to measure against. Membership is append-only: nothing can be removed or edited once added, so a fixture cannot be adjusted after the result is seen. Requires comparisons:write.

  shallow
• create_comparison_verdict

  Record an accept or reject call over the comparisons you name, under the default decision rule or thresholds you state. An undecided result records nothing and is reported instead. Requires comparisons:write.

  shallow
• create_consulting_client

  Create an account-private consulting client.

  shallow
• create_consulting_deliverable

  Create an internal draft deliverable on an owned engagement.

  shallow
• create_consulting_document_revision

  Create a revision-safe proposal or SOW draft on an owned engagement.

  shallow
• create_consulting_engagement

  Create an engagement for an owned consulting client.

  shallow
• create_content_asset

  Create a private draft content asset. There is no publish/send operation.

  shallow
• create_content_asset_revision

  Create a new owned draft revision from a frozen submitted/approved/rejected revision.

  shallow
• create_deal

  Create a sales deal owned by the caller. Provide a title, or a lead_id to inherit the lead's company/name as the title. The deal appears live on the owner's Sales board. No deletes are exposed over MCP.

  shallow
• create_invoice

  Create a draft invoice owned by the caller for a client, optionally seeded with line items and linked to an existing deal. Totals (subtotal/tax/total) are computed from the line items and tax_rate. The invoice starts in status 'draft' — call send_invoice to mark it sent.

  shallow
• create_marketing_audience

  Create an owner-private reusable audience definition.

  shallow
• create_marketing_brand

  Create an owner-private brand identity. Requires marketing:agent_write.

  shallow
• create_marketing_campaign

  Create an owner-private marketing campaign linked only to owned brand/audience ids.

  shallow
• create_monitor

  Save a standing watch that fires later, on its own: when a count you name crosses a line you set, do the thing you chose. Lets an agent bank a condition and stop polling for it. The watch survives the conversation that created it. Note that start_workflow spends the account's credits unattended each time it fires, so the cooldown is the only thing bounding what it costs. Requires authentication, a Pro or Enterprise account, and the monitors:write scope.

  shallow
• create_outreach_campaign

  Create a new outreach campaign owned by the authenticated user. Returns the new campaign id. Reversible (campaigns can be edited/deleted in the dashboard). Requires authentication.

  shallow
• create_outreach_pitch

  Create a reusable pitch template (subject + body templates, optional drafting prompt) owned by the user. Provenance is stamped source="agent" server-side. Returns the new pitch id. Requires authentication.

  shallow
• create_portfolio_report_share

  Create an expiring read-only bearer link for the exact previewed report projection. Anyone possessing the link can read it; copied content cannot be recalled. Requires explicit reports:share and independent human approval. Expiry must be UTC Z, 60 seconds to 30 days from creation. Acknowledge public visibility explicitly. Keep request_id and exact arguments after an uncertain reply; retrieve the original receipt with get_portfolio_report_share_receipt and read current link state. No link is sent.

  shallow
• create_portfolio_schedule

  Create an owner-private daily, weekly or monthly portfolio report schedule. Defaults to paused; explicitly enable to start internal captures. Uses the same active-ticket aggregate as manual reports. Optional project_id from project_list limits captures to that owned project; each report retains its own inputs. No email or provider calls. Preserve request_id and exact intent when retrying an uncertain reply. Requires tickets:write.

  shallow
• create_portfolio_snapshot

  Capture an immutable rollup of YOUR OWN ticket portfolio as it stands right now -- totals by status and priority, fixed at this moment and never recomputed. A snapshot is the durable 'here is where we were' that a later diff_portfolio_snapshots measures movement against, so capture one before a review rather than after. Snapshots cannot be edited or deleted once taken. The snapshot records the credential that captured it, so one taken by an agent is attributable as such. Requires authentication and the tickets:write scope.

  shallow
• create_portfolio_snapshot_note

  Record a decision or comment against one of YOUR OWN portfolio snapshots. Pass expected_content_hash -- the hash you saw when you read the snapshot -- and a mismatch is REFUSED rather than quietly filed against a different revision; that check is the point of this tool. Omitting it still records the note, it just does not assert which revision was on the screen. This writes down what was decided; it does not approve, reject or block anything, and nothing downstream gates on it. Requires authentication and the tickets:write scope.

  shallow
• create_report_review_envelope

  Freeze verified saved values with the definitions and disclosures shown now. Original-capture definitions are unavailable; this does not approve, share or hold data. Keep the exact request ID and fields after an uncertain reply. Requires tickets:write.

  shallow
• create_saved_view

  Save a named ticket filter, column, grouping and sort bundle so you can reopen it later or share it with a team. Saves the QUESTION, not an answer: the view is re-run against live tickets every time it is opened, so it never goes stale. The new view is private until you share it. Same endpoint the web app's save button uses. Requires authentication and the tickets:write scope.

  shallow
• create_scope_baseline

  Save immutable scope, estimates and explicit plan versions/dates for an owned delivery group. Reuse request_id on retries; a new request_id captures a new baseline. Requires tickets:write.

  shallow
• create_workflow_template

  Create a new custom workflow template the caller owns, so a multi-step pipeline can be built in conversation instead of by hand in the browser. Saves the same definition the web builder saves. The slug is derived from the name and is returned — use it with run_workflow. Steps run sequentially in the order given; depends_on is builder metadata only and does not change execution order. Requires authentication and the workflows:write scope.

  shallow
• decide_approval

  Answer a waiting checkpoint by request id: approve, reject, or amend. 'amend' means send the step back to be redone with the change described in notes, so notes are required for it. Spends money: approve continues the run and amend re-runs the step, both billed. Fails with a clear error, rather than silently doing nothing, if the run is no longer waiting. Requires authentication and the workflows:approve scope.

  shallow
• delete_accounting_run

  Permanently delete one private Accounting audit run owned by the caller. This is the only Accounting MCP deletion; it never files taxes, moves money, or contacts an external service.

  shallow
• delete_monitor

  Delete one of your standing watches, so it stops firing. Does not touch anything it already started. Requires authentication and the monitors:write scope.

  shallow
• delete_saved_view

  Permanently delete one of YOUR OWN saved views. UNRECOVERABLE -- there is no undo and the definition is not retained. archive_saved_view is the reversible retirement and is almost always what is wanted instead; use this only for a view that should actually be gone. Deleting a shared view removes it for the team too. Requires authentication and the tickets:write scope.

  shallow
• delete_workflow_template

  Delete a custom workflow template the caller owns. Built-in templates cannot be deleted. This removes the saved definition; runs already started from it are unaffected. Requires authentication and the workflows:write scope.

  shallow
• diff_portfolio_snapshots

  Compare two of your own portfolio snapshots and return the per-dimension movement between them. snapshot_id is always the 'to' side; against is the 'from' baseline, defaulting to your newest snapshot strictly older than it -- the 'what changed since last time' read, which is reported as not found when this is your first snapshot. Comparing an older snapshot against a newer one is allowed and disclosed rather than silently confusing: the result says whether the pair is chronological and the elapsed days go negative. Both sides are immutable, so a diff is reproducible indefinitely. Requires authentication and the tickets:read scope.

  shallow
• dismiss_ticket_integration_effect

  Settle one uncertain effect as owner-dismissed: you accept that its outcome stays unknown. Requires confirm true; makes no provider request and records one immutable settlement. A dismissed create can allow a later new create, so a duplicate remote item is the owner’s risk. Never retries or replays the effect. Refused until the deploy-owned settlement activation (graph v3). An effect left cancelled with attempt_count 1 cannot be dismissed. If an outcome is unconfirmed, read list_ticket_integration_effects_v2 before another action. Requires integrations:write and tickets:write.

  shallow
• draft_outreach_email

  Save a draft email subject and/or body onto one of the user's leads. This only stores the draft for human review — it does NOT send anything. A human sends from the dashboard. Requires authentication.

  shallow
• enable_attention_notification_rule

  Explicitly enable the exact owned configuration and start a fresh observation cycle. Requires notifications:send plus independent human approval of actual destinations, fields, stages and quiet hours. No priority bypass. Reuse exact request_id for uncertainty; retrieve the receipt then read current state. May cause signed webhook notifications; never sends email.

  shallow
• estimate_cost

  Estimate what a panel or saved workflow would cost before running it: returns a per-agent/per-step price breakdown, the total for the requested number of runs, your remaining quota and platform credit, an honest list of any models the platform could not price, and a go/no-go decision. Reserves nothing, charges nothing, starts nothing.

  shallow
• execute_saved_view

  Run a saved ticket view's stored filters against live tickets and return the matching tickets, the view that produced them, and group counts when the view groups. Results are always YOUR tickets: a shared view shares the question, not the answers, so opening a teammate's view runs it against your own work and never reveals theirs. An archived view is refused rather than executed. Returns the same payload the web app receives. Requires authentication and the tickets:read scope.

  shallow
• export_portfolio_snapshot

  Download one owned saved report using the same JSON, CSV, accessible HTML or optional tagged PDF renderer as the browser. Returns filename, media_type, encoding, content and SHA-256; PDF content is base64. Unsupported PDF fonts or renderer dependencies return an explicit error with HTML fallback. No network delivery or share link is created. Requires tickets:read.

  shallow
• export_report_review_envelope

  Export one verified frozen review record as versioned JSON or CSV, accessible HTML or optional tagged PDF. Returns exact bytes as UTF-8 or PDF base64 with SHA-256. PDF dependency or glyph failures offer HTML fallback. No delivery, share or approval is created. Requires tickets:read.

  shallow
• export_ticket_to_provider

  Export the exact previewed owned ticket to Jira or Linear, using expected_export_hash from preview_ticket_export and the same destination. Requires explicit integrations:write, tickets:write, and independent human approval of the complete preview. Persists the operation before possible remote writes. After an uncertain response, inspect list_ticket_provider_effects and reconcile the original intent; never blindly export again. Remote confirmation is observed, not atomic protection against concurrent remote writers.

  shallow
• get_accounting_run

  Get one private Accounting run owned by the caller, including its deterministic estimates, disclaimer, engine revision, and audit timestamps. Source input stays omitted unless include_input=true is explicitly requested.

  shallow
• get_agent_detail

  Full detail on one expert agent by slug (from list_agents): role, description, default model, domain, tags, and tools.

  shallow
• get_api_key_info

  Report the scopes, plan tier, expiry and remaining quota of the API key making this call, so an agent can check what it is allowed to do before attempting it rather than by being refused. Requires API-key authentication.

  shallow
• get_attention_notification_delivery

  Inspect exact retained notification payload and delivery state, with independent bounded attempt and recovery histories. Page attempts with next_before_attempt and recoveries with next_before_recovery_id separately. Uncertain is not delivered; owner received/cancel declarations do not rewrite network outcomes. Requires tickets:read.

  shallow
• get_attention_notification_receipt

  Recover the exact original request receipt without replaying or enabling delivery. Save receipts may contain destination signing secrets: requires notifications:manage. Historical receipt state is not current authority; read current state afterwards.

  shallow
• get_attention_notification_rule

  Read full owned notification configuration, copied selection, pinned quiet policy and health. Contains destination URLs but no signing secrets; handle privately. Requires notifications:manage.

  shallow
• get_availability

  Read current slots for one owned active meeting type in a window of at most 31 days. Existing host/provider gates and shared quotas apply. Availability is checked again before a booking; this read sends no invitation.

  shallow
• get_booking

  Read one owned booking and its bounded operation receipts for recovery. Includes private intake details. Does not redispatch an uncertain operation or reconstruct its manage credential.

  shallow
• get_business_suite_overview

  What needs attention across my business? Return the same private, counts-only review as the browser: Sales tasks, Marketing approvals, Accounting runs and Consulting work, with deterministic next actions. Legal is a governed entry point, not a verified review queue; generated Legal advice is disabled. No raw documents, amounts, contacts or private text are returned. Never sends, approves, pays or calls a provider. Requires the explicit business_suite:read scope, absent from default and legacy keys. Returns the canonical snapshot as JSON and structured data.

  shallow
• get_comparison_artifact

  Read one recorded comparison back exactly as it was stored. Requires comparisons:read.

  shallow
• get_comparison_eligibility

  Report per member whether it can still be compared, and why not when it cannot. Membership is permanent, so a member that became unreadable is reported as ineligible rather than quietly dropped. Requires comparisons:read.

  shallow
• get_comparison_set

  Read one comparison set and its membership in fixed order. Requires comparisons:read.

  shallow
• get_comparison_verdict

  Read one recorded verdict, the comparisons it was asked over, and the rule it was decided under. Requires comparisons:read.

  shallow
• get_consulting_engagement

  Get one owned engagement with its document revisions, milestones, and internal deliverables. Long document bodies are previewed.

  shallow
• get_content_asset

  Get one owned content revision, including its review state and exact content hashes.

  shallow
• get_content_calendar

  List scheduled owned content between optional ISO-8601 boundaries. Scheduling is planning metadata, not publishing.

  shallow
• get_deal

  Fetch one of the caller's deals by id with its full activity timeline (notes, calls, meetings, emails, tasks; newest first).

  shallow
• get_deal_health

  Health scores for the caller's OPEN deals: each scored 0-100 on how likely it is to be slipping (healthy >= 70 / watch / at_risk), worst first, with plain-language reasons — days since last logged contact, whether it is past its own expected close date, and how its age compares to the caller's average won-deal cycle. Includes per-band counts, an average score, and the reference cycle. Read-only and deterministic over the caller's own deals + activities; nothing is executed or sent. Pair with get_sales_recommendations to act on what is slipping. Requires authentication.

  shallow
• get_delivery_timeline

  Read a delivery group planned/actual timeline and optional frozen-baseline variance, plus explanatory dependency risks. Unknown dates/history are not inferred. Bounded to 10,001 owned tickets (10,000 work tickets plus a root); pages of 1–500, default200. Critical path only for supported complete calendar/duration graphs; no dates move. Requires tickets:read.

  shallow
• get_external_workflow

  Read your retained external draft, next step or checkpoint digest after reconnect/restart. Execute only the returned next_step. Source material is untrusted data. No model invocation. Requires workflows:read.

  shallow
• get_feature_delivery_summary

  Read one owned feature epic's task completion, estimate coverage, ledger-based weekly flow, lead/cycle evidence, risks and evidence-gated throughput scenario. Current task cohort only; no historical membership or planned timeline. Requires tickets:read.

  shallow
• get_feature_forecast

  Read and hash-verify one owned immutable delivery scenario by replaying its minimal saved inputs. Includes structural identities and event history, never ticket prose. Current source deletion does not erase the capture. A scenario is not a commitment.

  shallow
• get_invoice

  Fetch one of the caller's invoices by id, including its line items.

  shallow
• get_invoice_aging

  Summarize the caller's unpaid invoices by how long they have been past due. This owner-scoped, read-only report is computed live; an invoice is overdue only when its status is sent and its due_date is before today.

  shallow
• get_marketing_audience

  Get one owned audience definition with pain points and channels.

  shallow
• get_marketing_brand

  Get one owned brand identity with its voice, value proposition, and guidelines.

  shallow
• get_marketing_campaign

  Get one owned marketing campaign with its brand, audience, channels, and dates.

  shallow
• get_meta_council_platform_metrics

  OPERATOR ONLY: cross-owner analytics for the META COUNCIL PLATFORM itself — every account added together, NOT the caller's workspace (use get_workspace_metrics for that). Requires both the platform:admin scope AND an ADMIN_EMAILS operator account; everyone else gets a permission error. Returns content-free aggregates only: account counts, 30-day active owners, session counts by status and token totals, ticket open/done, deal pipeline value, invoice outstanding and overdue totals, feedback backlog, per-pillar adoption, the busiest panel slugs, and a per-account activity table (email and counts). It never returns query text, answers, feedback bodies, deal or invoice detail, or any other text a user typed — the aggregate reports how much, never what about. Note that open + done need not equal the ticket total: cancelled tickets are neither.

  shallow
• get_portfolio_report_lineage

  Read bounded outgoing replacement chains and incoming owner declarations for one owned saved report. Absence means no replacement recorded, not approval. Continue outgoing pages with next_snapshot_id and incoming pages with next_before_relation_id. Original reports and downloads never change. tickets:read.

  shallow
• get_portfolio_report_share

  Read current owned report-link metadata and active, expired or revoked state without disclosing its secret. Requires tickets:read. Stored report content remains unchanged.

  shallow
• get_portfolio_report_share_receipt

  Recover the exact original create/revoke receipt using its request_id, including the original bearer link for create. Requires explicit reports:share; no approval or new access is created. A receipt describes the original commit: separately get current link state before treating it as active.

  shallow
• get_portfolio_schedule

  Read an owned report schedule, next UTC time, configured local timezone and current capture health. Calendar disclosures explain skipped nonexistent times, the earlier repeated time and month-end clamping. Current health is not immutable failure history. Requires tickets:read.

  shallow
• get_portfolio_snapshot

  Fetch one portfolio snapshot by id: its label, schema version, the exact stored rollup payload, its content hash, who recorded it and when. The payload is served from storage and is never recomputed from live tickets, so a snapshot read today reports what was true when it was taken. A snapshot you do not own is reported as not found rather than as forbidden. Requires authentication and the tickets:read scope.

  shallow
• get_portfolio_snapshot_inputs

  Verify and return the retained minimal inputs and regenerated counts of one owned project report. Reads stored inputs only; later ticket moves or deletion do not recapture the report. Legacy reports without retained inputs return a precise unavailable dependency. Requires tickets:read.

  shallow
• get_project_attention_policy

  Read one owned project's current override or owner-policy inheritance, effective policy and immutable project history. Archived projects retain authority. Page history with next_before_revision while has_more. Requires tickets:read; no state changes.

  shallow
• get_report_review_envelope

  Read one owned frozen review record and source hash without rebuilding its definitions. No declaration or permission to share is inferred. Requires tickets:read.

  shallow
• get_sales_analytics

  Sales pipeline analytics for the caller: probability-weighted forecast, per-stage $ rollup, win rate (won / decided, by count and by value), average sales-cycle days over won deals, and open-deal aging with a stale count. Read-only; computed from the caller's own deals. Requires authentication.

  shallow
• get_sales_recommendations

  The caller's prioritized next-best sales actions: interested leads to convert, open deals gone stale enough to need a follow-up, and overdue tasks — each with a rationale and the exact governed tool to run next (convert_lead_to_deal / log_deal_activity / complete_sales_task) plus its arguments. Read-only; ranks the caller's own CRM data (overdue > convert > follow-up). Nothing is executed or sent — approve an item by calling the named write tool. Requires authentication.

  shallow
• get_saved_view

  Fetch one saved ticket view's definition by id: its name, filters, columns, grouping, sort and whether it is shared. This returns the view itself, not the tickets it selects -- use execute_saved_view to run it. A view you cannot read is reported as not found rather than as forbidden, so this cannot be used to discover that someone else's view exists. Requires authentication and the tickets:read scope.

  shallow
• get_scope_baseline

  Read frozen structural scope, estimates and captured explicit plans for an owned baseline. Older schema1 dates remain unknown. Requires tickets:read.

  shallow
• get_session

  Get the full results of a previous Meta Council session, including all agent opinions and the synthesis.

  shallow
• get_settings

  Get the authenticated user's Meta Council settings — preferred model, plan tier, and which provider/tool API keys are configured (booleans only, never the secret values). Requires authentication.

  shallow
• get_site_analytics

  OPERATOR ONLY: visitor traffic for the META COUNCIL PLATFORM's own website — every visitor added together, NOT the caller's workspace (use get_workspace_metrics for that) and NOT the business rollup (use get_meta_council_platform_metrics for that). Requires both the platform:admin scope AND an ADMIN_EMAILS operator account; everyone else gets a permission error naming which of the two requirements failed. Covers a window of whole UTC days ending today, set by days. Returns total views, unique visitors, the authenticated/anonymous split, the busiest public paths, the busiest in-app sections, top referrers and a per-day series, plus the window it covers so the caller need not track what it asked for. Page paths and in-app sections are counted separately and are not comparable to one another. It never returns per-visitor rows, email addresses, IP hashes, user agents, session identifiers or query text — the rollup reports how many, never who.

  shallow
• get_ticket_attention_policy

  Read the owner-private effective attention policy, built-in defaults, applicable statuses and immutable history. Requires tickets:read. limit 1–50 (default 20); exclusive before_revision. Earlier unrecorded history is unknown. No writes or providers.

  shallow
• get_ticket_attention_queue

  Read the same ranked Needs attention queue as the browser and REST. Returns complete JSON with reasons, UTC clock evidence, effective owner policy thresholds and revision, approximation flags, unmet prerequisites and suggested next actions. Open active owned tickets only; limit 1–500 (default 100), with total_flagged and truncated. Filter reason to find current epic completion blockers or one elapsed-clock reason before the limit. Completion blockers reuse current readiness and have no known age or threshold. Ranked by greatest known days over threshold, then ticket UUID; items with no elapsed clock sort last. No state changes, acknowledgments, notifications or provider calls. Requires tickets:read.

  shallow
• get_ticket_attention_resolution

  Inspect original reviewed evidence, a separately labeled fresh assessment and immutable owner resolution history. Requires tickets:read. limit 1–50, exclusive before_revision. Current state always refers to the latest review; unavailable work is not proof of deletion or resolution.

  shallow
• get_ticket_attention_review

  Read the owner-private current attention assessment, latest review and immutable history. Requires tickets:read. History uses limit 1–50 (default 20) and exclusive before_revision; stays readable after ticket closure/archive/deletion. Evidence-changed and follow-up-due are separate states. Dates become due at start of their recorded IANA calendar day. No writes or providers.

  shallow
• get_ticket_burndown

  Daily burndown series replayed from the append-only ticket ledger: per-day scope (existing, non-cancelled), remaining, done levels plus added/completed flows, with a summary. Optionally scope to one epic's current subtree via root_id. Backfill (legacy_snapshot) rows seed state but never count as additions. days clamps to 7-180 (default 30). Optionally pass target_date to overlay a straight-line plan: an ideal series descending from the window-start remaining to zero on that date, for reading actual against plan.

  shallow
• get_ticket_delivery_plan

  Read the explicit dated plan of an owned ticket, including archived or retained deleted-ticket plans. Absent plans remain unknown. Requires tickets:read.

  shallow
• get_ticket_external_links

  Read one owned ticket’s saved GitHub, GitLab and Asana links plus unresolved write effects that need reconciliation. Remote status is the last observed value, not live state. No provider request. Requires integrations:read and tickets:read.

  shallow
• get_ticket_integration_import_receipt

  Read this owner’s retained GitHub, GitLab or Asana import receipt for one exact request_id: created ticket IDs and count only, never imported content. found false does not prove an import failed. No provider request or retry. Requires integrations:read and tickets:read.

  shallow
• get_ticket_label_cohort

  Report a fixed cohort holding one exact label at the UTC window start, observed daily task completions/reopens, status and point coverage. Today's labels never rewrite history. end_date is exclusive; default today UTC. Bounded cursor pagination; unknown history is disclosed.

  shallow
• get_ticket_label_history

  Read immutable owner-private observed label assignments/removals, revision bindings and legacy limits. Retains deleted tickets. Bounded cursor pagination; no provider or ticket changes.

  shallow
• get_ticket_projects

  Projects overview of the caller's board: one entry per top-level epic with recursive descendant progress (done %, counts by status, blocked, points, sub-epics, last activity), plus a triage strip of unrouted work (backlog + unassigned root tickets). Read-only, recomputed live. Use this before planning a session to see initiative health at a glance; use ticket_list/ticket_get to drill into any id it returns.

  shallow
• get_ticket_provider_field_options

  List eligible exact owner credential identities/generations and fixed origins for explicit field capture. Never returns secret material or contacts a provider. Configure credentials in Settings; this tool creates no credential or grant. Requires integrations:read and tickets:read.

  shallow
• get_ticket_provider_field_request

  Read this owner’s exact retained link/check/archive request result. An attempted/unknown request is not permission to repeat a remote read. A missing request does not prove an earlier save could not finish. No provider request. Requires tickets:read.

  shallow
• get_visualization

  Fetch a chart artifact generated by a council session or LOCUS determination. Returns the machine-readable spec (the data behind the chart) plus the stable SVG URL, or the raw SVG itself with include_svg=true. Artifact ids appear in session results as 'visualizations' / 'visualization' reference blocks. Requires authentication and enforces the artifact owner's tenant boundary.

  shallow
• get_workflow_session

  Poll a previously started workflow run for its current step-by-step status and output (useful when run_workflow timed out or is awaiting a checkpoint). Requires authentication.

  shallow
• get_workspace_metrics

  One cross-domain rollup of the caller's own workspace: council sessions (total, last 30 days, by status, tokens), feedback ratings, tickets (open/done), deals (count by stage, open pipeline value) and invoices (count by status, outstanding total, overdue count). Read-only, recomputed live, and scoped to the caller — it never aggregates across accounts. Use it for a single 'how is this workspace doing' answer instead of calling the per-domain analytics tools one by one; use those (get_sales_analytics, get_ticket_projects, list_invoices) to drill into whatever this surfaces. Counts of unrecognised stages or statuses are reported under 'unknown' rather than dropped, so each breakdown sums to its own total. Note that open + done need not equal the ticket total: cancelled tickets are neither. Invoice overdue status is computed at read time by comparing due dates against now, not stored on the record, so it is current as of this call and an invoice due today does not yet count as overdue.

  shallow
• initialize_consulting_milestones

  Idempotently initialize stable engagement milestones. Retries return the same ids and external refs.

  shallow
• link_ticket_provider_fields

  Link and check one explicitly selected remote item. GitHub container owner/repo + issue number; GitLab project numeric ID + issue iid; Azure organization/project UUID + work item ID; Asana workspace gid + task gid; Jira project key + issue key; Linear team UUID + issue UUID. New providers require exact configured credential_id; Jira/Linear use existing owner Settings credentials. Fixed hosted origins only, no remote writes. Immutable IDs are pinned only after a matching response. Reuse the exact request_id/arguments after lost replies; unknown attempts never redispatch. Requires integrations:read and tickets:write.

  shallow
• list_accounting_runs

  List only the caller's private Accounting-run audit metadata, newest first. Raw source text and analysis results are intentionally omitted.

  shallow
• list_agents

  List all available expert agents with their roles, domains, and specialties.

  shallow
• list_approvals

  List workflow checkpoints waiting on you, soonest deadline first, with which step is paused and when it runs out. Defaults to the pending ones. Requires authentication and the workflows:read scope.

  shallow
• list_attention_notification_deliveries

  List owned notification delivery metadata by optional rule and current state. No URL paths or signing secrets. Follow next_before_id while has_more; live state may change. Requires tickets:read.

  shallow
• list_attention_notification_revisions

  Read immutable notification configuration revisions, including private destination URLs and frozen selection, newest revision first. Follow next_before_revision while has_more. Requires notifications:manage; no signing secrets.

  shallow
• list_attention_notification_rules

  List owned notification metadata without destination paths or signing secrets. Scope active includes paused unarchived rules; archived/all also available. Follow next_before_id while has_more; membership is live. Requires tickets:read.

  shallow
• list_booking_followups

  Read owner-only in-app meeting prompts or due follow-up tasks. Matches the app view and uses current task due/done state; page membership can change. No message or Calendar change is sent.

  shallow
• list_bookings

  Read an owner-only page of up to 50 bookings. Continue with next_after; archived defaults to false. Includes recipient details, never manage credentials or raw Calendar access.

  shallow
• list_campaign_replies

  List sent / received emails for an outreach campaign, newest first — subject, body preview, and reply classification. Requires authentication.

  shallow
• list_campaign_triggers

  List automation triggers (auto-reply rules, status updates, notifications) configured for an outreach campaign. Requires authentication.

  shallow
• list_comparison_sets

  List your comparison sets, newest first, without their membership. Requires comparisons:read.

  shallow
• list_consulting_clients

  List consulting clients owned by the API-key account.

  shallow
• list_consulting_engagements

  List consulting engagements owned by the API-key account.

  shallow
• list_content_assets

  List owned content assets and immutable revisions; content is never published by this tool.

  shallow
• list_deals

  List the caller's sales deals (newest first) together with a weighted pipeline forecast (open/weighted/won totals). Optionally filter by stage or lead_id. Deals are private to the API-key owner.

  shallow
• list_feature_forecasts

  Page owned immutable capture identities for an epic, including one later deleted. Default limit20, maximum50. Continue with next_before_id while has_more. This metadata list does not replay inputs; use get_feature_forecast for verification. No automatic captures.

  shallow
• list_integrations

  List which outside services the authenticated user has connected — ticket boards, stored connector credentials (name, kind, whether configured, and when last verified) and the connectors available to call them. Returns configured / not configured facts, names and dates ONLY, and never returns a secret value. Read this before planning a workflow that reaches an external service, so a step is not written against a credential the user has not registered. Requires authentication.

  shallow
• list_invoices

  List the caller's invoices (newest first), optionally filtered by status (draft/sent/paid/void). Each entry includes its computed overdue flag.

  shallow
• list_marketing_audiences

  List reusable marketing audiences owned by the API-key account.

  shallow
• list_marketing_brands

  List brand identities owned by the API-key account.

  shallow
• list_marketing_campaigns

  List owned marketing campaigns. These are separate from Sales outreach campaigns.

  shallow
• list_meeting_types

  Read the owner's bounded saved meeting types, including inactive types. Does not activate booking or expose Calendar credentials.

  shallow
• list_meta_council_feedback

  ADMIN ONLY: list platform-feedback reports — feedback about Meta Council itself, never a tenant's own business data — across all users for triage (requires an ADMIN_EMAILS account; everyone else gets a permission error). Filter by status, category, or severity.

  shallow
• list_monitors

  List the standing watches you have saved, newest first, with what each one watches, what it does, and when it last fired. Requires authentication and the monitors:read scope.

  shallow
• list_outreach_campaigns

  List the authenticated user's outreach campaigns with live lead / sent / reply counts. Requires authentication.

  shallow
• list_panels

  List all available expert panels with their descriptions and agent counts.

  shallow
• list_portfolio_report_history

  Browse owned saved reports in portfolio (default), project or all scopes, newest first. Project scope requires project_id. Each report supplies its immutable ID and payload hash for comparisons or replacement declarations. Continue with next_before_id while has_more; omit the cursor to refresh newest captures. Counts are stored rollups, not accuracy or approval claims. tickets:read.

  shallow
• list_portfolio_report_shares

  List owned report links in newest creation-time/ID order, optionally for one owned report. Scope all, active, expired or revoked is live on each page. Follow next_before_id while has_more; refresh newest for changes. Metadata contains no bearer secret. Requires tickets:read.

  shallow
• list_portfolio_schedule_captures

  Read successful captures for one owned report schedule, including scheduled_for, actual captured_at, missed_count and the exact retained snapshot identity/hash. Downtime coalesces to one current capture, never fabricated historical counts. Follow next_before_id while has_more; report readers and exports open snapshot_id. Requires tickets:read.

  shallow
• list_portfolio_schedule_revisions

  Read immutable definition revisions of one owned report schedule, including paused or archived schedules. Newest revision first; follow next_before_revision while has_more. No capture or state change. Requires tickets:read.

  shallow
• list_portfolio_schedules

  List the caller's private report schedules in newest creation-time/ID order. Active includes paused schedules. Follow next_before_id while has_more; current archive membership is rechecked on each live page. Requires tickets:read.

  shallow
• list_portfolio_snapshot_notes

  Read the decision and comment thread recorded against one of your portfolio snapshots, oldest first. Each note carries the snapshot content hash it was written against plus binding_intact comparing that hash to the snapshot's hash now, so a note can be read as evidence of what was actually on the screen when it was written. Counts are over the notes actually returned, so a truncated page never reports a total it did not show. This reads the thread; it does not approve, reject or block anything. Requires authentication and the tickets:read scope.

  shallow
• list_portfolio_snapshots

  List your own portfolio snapshots, newest first: the immutable rollups of how your ticket portfolio stood at the moments you captured them. Each carries its label, schema version, stored payload, content hash, recording actor and creation time. Snapshots are owner-private and never span accounts. Returns the same payload the web app's snapshot list returns. Requires authentication and the tickets:read scope.

  shallow
• list_report_review_declarations

  Read the append-only owner declaration history and current derived head for one exact review record. Approval is an owner declaration, not independent review, signature, sharing or legal-hold authority. Only a JWT owner session can approve or withdraw. Requires tickets:read.

  shallow
• list_report_review_envelopes

  List immutable review records for one owned saved snapshot, newest first. Limit 1–100; use next_before_id while has_more. Records preserve review-time interpretation, not original-capture definitions. Requires tickets:read.

  shallow
• list_reviewed_attention

  Discover latest owned attention reviews, including cleared, terminal, archived and unavailable work. Requires tickets:read. Filter unresolved (including withdrawn), resolved or all; independently set follow_up=due for saved follow-ups whose stored UTC instant has arrived. Due pages sort oldest first and retain their cutoff; refresh without a cursor for newly due work. Latest-review and declaration membership remain live. limit 1–50, owner/filter-bound cursor. Current ticket metadata is separate from retained reviewed evidence. No queue filtering or providers.

  shallow
• list_sales_tasks

  List the caller's open sales tasks (activities of type 'task' not yet done), bucketed overdue / today / upcoming and ordered most-urgent-first with per-bucket counts. Close one with complete_sales_task.

  shallow
• list_saved_views

  List saved ticket views you can open: the stored filter, column, grouping and sort combinations saved by you, plus any shared with a team you belong to. Shared views appear under the active and all scopes and never once archived, because an owner's archive is their own working state. Returns the same payload the web app's saved-view list returns. Requires authentication and the tickets:read scope.

  shallow
• list_scope_baselines

  List saved baselines for an owned delivery group, newest first. Includes retained baselines after group deletion. Requires tickets:read.

  shallow
• list_ticket_delivery_plan_history

  Read immutable plan revisions, newest first, including retained deleted-ticket history. Continue with next_before_version. Requires tickets:read.

  shallow
• list_ticket_integration_connections

  List this owner’s saved GitHub, GitLab or Asana connections from the local record: labels, remote project and account identity, stored health and timestamps. Health is the last recorded check, not live status. Never returns credentials or fingerprints. No provider request. Requires integrations:read and tickets:read.

  shallow
• list_ticket_integration_effects

  Read a bounded newest-first page of one owned ticket’s recorded GitHub, GitLab and Asana write effects: operation, target status, state, last outcome, correlation ID and timestamps. Never returns payloads. Default 20, maximum 50; use next_before_id while has_more. No provider request, retry or reconciliation. Requires integrations:read and tickets:read.

  shallow
• list_ticket_integration_effects_v2

  Version 2 of list_ticket_integration_effects: the same bounded newest-first page of one owned ticket’s recorded GitHub, GitLab and Asana write effects, plus whether each still blocks integration writes and its immutable settlement, if any. graph is v2 until the deploy-owned settlement activation and v3 after it; v2 shows no settlements. An effect left cancelled with attempt_count 1 still blocks and cannot be settled. Never returns payloads. Default 20, maximum 50; use next_before_id while has_more. No provider request, retry or reconciliation. Requires integrations:read and tickets:read.

  shallow
• list_ticket_provider_effects

  Read bounded retained export and transition outcomes for an owned ticket. Requires tickets:read (or tickets:write). Follow next_before_id while has_more. Returns metadata only, never encrypted payloads, credentials or fresh provider state. Intent IDs identify original uncertain operations; historical outcomes are not permission to resend.

  shallow
• list_ticket_provider_fields

  Read a bounded page of encrypted owner-private field captures (decrypted only for their owner), exact target coordinates and current local comparison. Default20, maximum50; use next_before_id while has_more. Includes retained source-deletion history. Recent means checked within24hours, not live state. No provider request. Requires tickets:read.

  shallow
• list_ticket_provider_observations

  Read owner-private retained Jira/Linear status observations and effect evidence, optionally scoped to a ticket/provider. Includes deleted-ticket history. Follow next_before_id while has_more, limit 1–100. Requires tickets:read or tickets:write; no provider request or credential decryption. Historical checks are not proof of current remote state.

  shallow
• list_workflows

  List available multi-step workflow pipelines (composable bundles that chain several steps, each able to run on its own model/provider). Returns each workflow's slug, description, per-step model, and definition_sha — a fingerprint of that definition as loaded right now, comparable against the definition_sha reported by a run you start later.

  shallow
• locus_determine_from_scores

  Compute a LOCUS Level of Care from dimension ratings you already have. Deterministic — no LLM, instant: composite + Determination Grid + the inviolable override floors (e.g. Risk-of-Harm=4 → minimum Level 5), applied in code. Provide EITHER the seven flat D* ratings (1-5 each; Dimension IV splits into IV-A Stress / IV-B Support) OR a per-reviewer agent_scores map. Sending both is refused (422) rather than scored: agent_scores would win and your flat ratings would be discarded, override floors included. Requires authentication.

  shallow
• log_deal_activity

  Log an activity on a deal (or lead) — a note/call/meeting/email, or a follow-up task with a due date. Pass deal_id and/or lead_id (each must be owned by the caller). type defaults to 'note'; for a task set type='task' and a due_date (YYYY-MM-DD). Tasks appear in list_sales_tasks.

  shallow
• mark_invoice_paid

  Mark a draft or sent invoice as paid (stamps paid_at). Cannot be applied to a void invoice. invoice_id is required.

  shallow
• mint_child_api_key

  Mint a short-lived child API key for a delegated subtask. The child can never exceed the calling key: requested scopes must be a subset of what the caller holds, its expiry is capped by the caller's, and it may never itself mint keys (delegation is exactly one level deep). A caller whose own scopes were never recorded explicitly cannot delegate at all until it rotates first. The child key is returned exactly once in the response and cannot be retrieved again; revoking the parent immediately revokes the child. Requires the keys:mint scope.

  shallow
• outreach_analytics

  Outreach summary for the user — total leads, sent, replied, and reply rate. Requires authentication.

  shallow
• pause_attention_notification_rule

  Pause an owned notification rule using current expected_revision; archived=true also archives it, archived=false restores it paused. Cancels future eligible sends from that activation, preserving prior outcomes. Requires notifications:manage; no human approval needed to reduce delivery. Exact request_id retries return the original receipt.

  shallow
• plan_council

  Resolve the effective Council models, parameters, tools, and setup reasons for this account without starting a session, calling a provider, or recording usage.

  shallow
• plan_workflow

  Preview what a workflow WOULD do, without running it. Costs nothing and runs no models: returns the step execution order, each step's role/model/max_tokens and whether it pauses for a human checkpoint, the workflow's declared parameters (validated if you supply values), which required integrations your account already has credentials on file for, an upper-bound cost estimate, and definition_sha — a fingerprint of the definition this plan was built from, which tells you whether the definition changed between planning and running but never hands back the definition itself. Starts no session and records no usage. Use before run_workflow to check a pipeline fits before spending on it. Requires authentication.

  shallow
• preview_accounting_ticket_sync

  Preview, without writing, how one completed owned Accounting run's WRITEOff work plan would map to stable Meta Council tickets. Reports creates, updates, unchanged tickets, human-edited generated fields that will be preserved, and identity conflicts. Requires both accounting:read and tickets:read; tickets:write also satisfies the ticket-read grant. Preview before committing because tickets are not field-encrypted; work-plan text may reproduce source-derived snippets or parser details, and after commit tickets:read can read it without accounting:read. Check the item count before committing. Statement-derived runs currently plan one ticket per unclassified transaction line, so a several-hundred-row statement plans several hundred tickets. When the count is large, report it and confirm with the owner rather than committing a board-flooding sync.

  shallow
• preview_attention_notification_rule

  Preview a draft definition or one owned saved notification rule, never both. Lists the exact selected public notification fields and current canonical matches; page all matches by next_before_id. Copied saved-view selection is frozen on save. Creates no notification or external call. Requires notifications:manage.

  shallow
• preview_portfolio_report_share

  Preview the exact public projection of an owned saved report, including its label, capture time, identity, fixed counts and disclosure. Private notes and unmodeled payload fields are excluded. Review this projection before requesting a link. Requires tickets:read; creates no access.

  shallow
• preview_scheduling_action

  Freeze exactly one create, reschedule or cancel proposal for ten minutes. Sending requires separate explicit authenticated owner-session confirmation plus scheduling:agent_write and scheduling:invite_send. Preview sends no invitation; it grants no permission itself.

  shallow
• preview_ticket_export

  Preview the exact owned ticket content, destination, correlation marker and status mapping for Jira or Linear. Supply destination (Jira project key or Linear team key) for an unlinked ticket. Returns expected export hash; no provider request or external write. Requires explicit integrations:write and tickets:write. Review this preview before export; a changed ticket or provider credential needs a fresh preview.

  shallow
• preview_ticket_integration_import

  Re-read 1 to 20 selected items live from the provider and return their exact importable content plus a fingerprint for commit_ticket_integration_import. Selection items as browse returns them: GitHub {id, number}, GitLab {id, iid}, Asana task gid strings. Read-only provider requests; creates nothing. Requires integrations:read and tickets:read.

  shallow
• project_create

  Create an owner-private project with intent and goals. Persist request_id before calling; retry exact input after an uncertain response. Does not start work or create tickets.

  shallow
• project_document_create

  Save the first immutable project brief, PRD, technical specification or decision revision. Optional ticket_id scopes the document to a linked feature. reviewed is editorial metadata, never execution approval.

  shallow
• project_document_get

  Read one exact owned project document revision and its bounded revision history. Omit revision for latest; use explicit revision when recording evidence.

  shallow
• project_document_revise

  Append an immutable document revision using expected_revision and a caller-retained request_id. Exact retry reconciles even after later edits; changed input or stale base conflicts. No provider execution or external publication.

  shallow
• project_get

  Read project intent, current document IDs/revisions and linked feature epics. Read document bodies with project_document_get and follow ticket_get/ticket_list for execution work.

  shallow
• project_link_feature

  Link an existing owned parentless epic to this project. Exact retry reuses the link; linking an epic already belonging to another project conflicts. Does not reparent, claim or execute the ticket.

  shallow
• project_list

  List the account's overarching project workspaces, separate from feature epics. Requires tickets:read.

  shallow
• project_unlink_feature

  Remove one exact project-feature placement, retaining the ticket. Read binding_id from project_get first; stale bindings or document references conflict. Does not delete tickets or documents.

  shallow
• project_update

  Revision-safely edit project context. Supply expected_revision from project_get and a new request_id. Stale edits conflict instead of overwriting another agent.

  shallow
• recommend_panel

  Recommend the best expert panel for a query (semantic match with keyword fallback). Returns the top panel + confidence and the runner-up options — feed the result into run_council's panel argument. Requires authentication because the query may be sent to the configured embedding provider.

  shallow
• reconcile_attention_notification_delivery

  Record an owner declaration received or cancel with a note and current expected_version. Original network outcome and recovery history remain immutable. This is an attestation, never a fabricated receipt or permission to send again. Requires notifications:manage.

  shallow
• reconcile_ticket_provider_effect

  Check the original Jira or Linear intent against provider correlation/status using read-only provider requests. Requires explicit integrations:read and tickets:write. May record recovered local linkage/outcome; never creates a remote issue or sends a status transition. Missing, multiple, mismatched or unavailable evidence remains pending review. A changed credential cannot redirect the original operation. Use the original intent_id from list_ticket_provider_effects.

  shallow
• record_outreach_evidence

  Record owner-observed identity, employer, published work email, mailbox result/expiry and source-policy observations. This does not independently verify facts, create consent, enroll or send. Requires outreach:write.

  shallow
• record_ticket_attention_resolution

  Record or withdraw an owner resolution with a required explanation, latest review ID/revision, resolution revision and fresh assessment digest. Requires tickets:write. Use a stable idempotency key; exact retries return the original receipt, conflicts require fresh inspection. Resolution never changes tickets, queue membership, clocks, policy, reviews, follow-ups or action authority. A newer review starts unresolved. No providers or notifications.

  shallow
• reject_content_asset

  Reject a submitted owned revision with optional reviewer notes. Requires marketing:approve.

  shallow
• reopen_consulting_deliverable

  Return an unapproved review deliverable to editable draft status.

  shallow
• reschedule_booking

  Commit the exact owner-confirmed reschedule preview using both independent scheduling grants. This can notify the recipient, including cancellation. Reuse the same preview, hash and confirmation reference after uncertainty. Missing private process custody permits receipt recovery but cannot authorize a new dispatch; no manage secret is reconstructed.

  shallow
• restore_accounting_run

  Restore one owned soft-deleted Accounting run to normal lists and reads, retaining its original encrypted data and provenance. Repeating restore is safe. No external service is contacted.

  shallow
• restore_saved_view

  Return one of YOUR OWN archived saved views to the working set with its definition intact. Idempotent -- restoring a view that is already active is a no-op rather than an error. Use list_saved_views with scope=archived to find restorable views. Requires authentication and the tickets:write scope.

  shallow
• retry_attention_notification_delivery

  Explicitly retry an eligible notification using expected_version and acknowledge_possible_duplicate=true. Requires notifications:send plus independent human approval. Preserves event/body/ID for receiver deduplication; cannot promise exactly once. An uncertain response must be reconciled through its request receipt before further action.

  shallow
• retry_workflow

  Continue a stalled or finished workflow run from a chosen step. This starts a NEW run that reuses the outputs the original run already recorded and only executes — and only pays for — the steps from 'from_step' onward. The original run is left untouched and the new one records which run it continues. Omit 'from_step' to resume at the first step that has no recorded output. A step whose output was never recorded is re-run, never skipped. Requires authentication.

  shallow
• review_external_workflow

  Approve continuation or reject an ordinary internal draft checkpoint using its review_sha as input_sha. This is not a human-only approval or permission to send. Human-only gates are unsupported and refused at start. Requires workflows:approve.

  shallow
• revoke_portfolio_report_share

  Revoke future reads through an owned report link. Requires explicit reports:share; reducing access does not need another human approval. Already copied content cannot be recalled. Preserve request_id for exact retry or receipt recovery; no report content is changed.

  shallow
• rotate_api_key

  Replace the API key making this call with a fresh one carrying the same scopes. WARNING: this IRREVERSIBLY deactivates the current key the moment it succeeds — every other caller using that key stops working immediately, so do not call it on a shared credential. The new key is returned exactly once in the response and cannot be retrieved again. A delegated child key cannot rotate itself. Requires API-key authentication.

  shallow
• run_comparison

  Re-run a member's workflow as it stands today and record the result as a new run. This calls model providers and costs money; it is priced and refused against your budget before anything starts. It does not act on the outside world a second time: connector steps are served from the baseline's recorded responses and agent steps keep only offline calculation tools. Returns the new run, not a comparison of it. Requires comparisons:write and workflows:run.

  shallow
• run_council

  Submit a question or decision to Meta Council. A panel of specialized AI agents will independently analyze it, then a synthesis step combines their opinions into a unified recommendation with full transparency. Starts asynchronously by default; use get_session with the returned session id.

  shallow
• run_workflow

  Start a multi-step workflow pipeline and return its session id immediately by default. Poll get_workflow_session for each step's model/provider and output. synthesis. Steps run on YOUR configured provider keys, so a pipeline can chain models across providers. If a step is a human checkpoint, returns the session id to advance. Requires authentication.

  shallow
• save_attention_notification_rule

  Save a full owner notification configuration bound to expected_preview_hash; existing rules also require rule_id and expected_revision. Save always pauses. New/replaced or explicitly rotated destination keys appear only in the original receipt; retain request_id for recovery. URLs may contain credentials and remain private. Requires notifications:manage; never enables delivery.

  shallow
• save_project_attention_policy

  Record a complete project attention override or restore owner inheritance prospectively. Override requires explicit paused_statuses for all four reasons. Uses the project's expected_revision and an owner-wide idempotency_key. Exact retries return the original receipt, not current state: read current policy separately. Preserves anchors and historical pauses. Requires tickets:write; no external communication or team governance.

  shallow
• save_ticket_attention_policy

  Save owner-private attention thresholds and status overrides in elapsed UTC days (finite 0–3650). Requires tickets:write. Supply full base thresholds, sparse status overrides, expected_revision (0 first) and caller-stable idempotency_key. Null only in an override disables that rule, never pauses clocks. Each save/restoration creates immutable history and invalidates earlier attention reviews. Exact retry returns original saved_policy receipt, which may no longer be current; read effective policy separately. No ticket status, clock, notification or provider changes.

  shallow
• save_ticket_attention_review

  Record an owner-private review of current attention evidence, with optional note (2000 characters) and follow_up_date plus explicit IANA follow_up_timezone, or null for both. Requires tickets:write. Supply the current evidence digest, current review revision (0 first), and caller-stable idempotency key. Exact retries return the original receipt; changed requests, revision or evidence conflict. Retains immutable history; omitted fields clear note/date. Does not hide/reorder queue items, reset clocks/status, approve consequential actions, notify or call providers. Retained evidence discloses omitted prerequisite detail.

  shallow
• save_ticket_delivery_plan

  Explicitly replace or clear a ticket plan. Dates and working-day duration are separate from points. Pass current expected_version; reuse exact request_id on retries. Changed saves atomically record immutable revision and plan_changed history. No automatic scheduling/execution. Requires tickets:write.

  shallow
• score_locus_case

  Score an anonymized adult mental-health / addiction case against LOCUS. Convenes the LOCUS Assessment Panel (psychiatrist, addiction specialist, clinical social worker, utilization reviewer, peer specialist, safety officer); each reviewer independently rates all six LOCUS dimensions, then a DETERMINISTIC engine aggregates the ratings and applies the Determination Grid and the inviolable override floors IN CODE (safety floors like Risk-of-Harm=4 → Level 5 cannot be reasoned away). Returns the recommended Level of Care with a full audit trail. Adults only (CALOCUS/CASII covers child/adolescent); use ONLY anonymized cases. Starts asynchronously by default; poll get_session. Requires authentication.

  shallow
• search_outreach_leads

  Search the user's outreach leads — filter by a text query (company / contact / email), pipeline status, and/or campaign. Returns company, contact, status, pitch, and reply info. Requires authentication.

  shallow
• send_invoice

  Mark a draft invoice as sent (stamps issued_at). Re-sending an already-sent invoice is a harmless no-op. invoice_id is required.

  shallow
• set_outreach_sender_state

  Record an owner-observed sender posture and checked time. This does not inspect credentials or verify a provider. Unknown, paused and unsafe remain held; verified alone cannot permit a send. Requires outreach:write.

  shallow
• share_saved_view

  Share one of YOUR OWN saved views with a single team you belong to. Members may read, list and execute it; only you may revise, re-share or delete it. Executing a shared view runs it against the READER's own tickets, so this shares the question and never the answers. Re-sharing to a different team MOVES the view rather than adding a second grant -- a view is readable by at most one team. Note: team ids are not currently discoverable from this MCP surface, so supply one you already hold. Requires authentication and the tickets:write scope.

  shallow
• start_external_workflow

  Start a caller-executed sales evidence draft. Returns frozen instructions for your agent to execute. No server model call, tools or sending. Reuse request_id only with identical inputs. Results are caller attestations, not verified provider usage. Requires workflows:run.

  shallow
• submit_consulting_deliverable

  Submit an owned draft deliverable for internal review without publishing it.

  shallow
• submit_content_asset

  Submit an owned draft for review, freezing that exact revision and content hash.

  shallow
• submit_external_workflow_result

  Submit your output for the exact next_step input_sha and step_index. Retains authenticated caller provenance; model_label is self-reported. Identical retries are safe; conflicting/stale results fail. No server model call or outbound action. Requires workflows:run.

  shallow
• submit_meta_council_feedback

  Report feedback about the META COUNCIL PLATFORM itself — a noticeable performance failure, a lacking/missing capability, a bug, or a UX/docs gap in Meta Council's tools, councils, workflows, or MCP surface. Platform feedback only: do NOT use this for anything about your own business, customers, deals, invoices, or other data Meta Council manages on your behalf — use the relevant business tool for that instead (e.g. create_deal, create_invoice). Use it the moment a tool result, council run, or workflow falls short. Stored per-user and visible only to platform admins — the response returns an id + acknowledgement and submissions cannot be read back. Include machine context (tool name, session id, model) in the context object.

  shallow
• supersede_portfolio_report

  Record that one owned saved report replaces another, with a required reason and both fetched payload hashes. This is an immutable owner declaration, not approval, sharing or a claim of accuracy. Both reports must have no replacement recorded. Use the same key and exact payload after an uncertain response; exact retries return the original receipt even after later replacements. Conflicting keys, self-links and cycles are refused. Original exports stay unchanged. tickets:write.

  shallow
• sync_accounting_tickets

  Commit a previously previewed completed Accounting run's WRITEOff work plan to stable owner-private Meta Council tickets. The expected_plan_hash from the preview is required, retries are idempotent, stable references prevent duplicate tickets across reprocessed runs, and human edits to generated content fields are preserved. Status, assignee, hierarchy, and completion are not reset. Requires both accounting:read and tickets:write. This creates or updates only in-platform planning tickets; they are not field-encrypted and become readable through tickets:read without accounting:read. It never files, pays, sends, or publishes anything.

  shallow
• test_workflow_step

  Run exactly ONE step of a workflow and return what it produced, so you can iterate on a single step's wording without running the steps before it. THIS SPENDS CREDITS EXACTLY LIKE A REAL STEP: the step runs on a real model through the same engine a full run uses and is billed identically -- it is not a simulation, a dry run, or a free preview. If you want to check a workflow's shape, parameters, models and cost estimate for free, use plan_workflow instead; that one runs nothing. Starts no session, so there is nothing to poll and nothing to advance. Requires authentication.

  shallow
• ticket_archive

  Retire an owned ticket from the working set, or restore one. Archiving is a different axis from status: the ticket keeps whatever status it had, so a done ticket stays done and a blocked one comes back still blocked — never use status 'cancelled' to mean 'archived'. An archived ticket disappears from ticket_list, the stats, the buckets, the attention queue, and outbound JIRA/Linear sync, but keeps its id and URL so citations stay valid, and it refuses edits until restored. Cascades to the active subtree; restore brings back exactly what was archived alongside it. Nothing is destroyed — this is not a delete, and no delete tool is exposed.

  shallow
• ticket_authority

  Read an owned ticket's audited current readiness, dependencies, current and stale scenario validation metadata, and immutable completion history. Archived tickets remain readable. History windows explicitly report truncation; use ticket_authority_export for all retained evidence. Returns exact canonical JSON without raw evidence payloads. Requires tickets:read.

  shallow
• ticket_authority_export

  Export the full owner-private ticket authority as canonical versioned native JSON, including retained dependency removals, revisions, validation evidence and completion manifests with their stored hashes and order. Includes private evidence; keep the file private. Export is capped at 64 MiB and refuses rather than truncating. The embedded integrity hash does not grant import or completion authority. Requires tickets:read.

  shallow
• ticket_batch_create

  Preview or idempotently commit one atomic owner-private batch of structured tickets and nested subtickets. Preview is non-mutating and returns the normalized commit payload, exact preview_token, and deterministic predicted IDs as JSON. Commit requires that exact token: combine commit_payload with mode=commit, the caller-held idempotency_key, and preview_token. It returns the same IDs plus replay status. A caller-stable visible-ASCII idempotency_key is always required. MCP authorship is stamped by the server; callers cannot spoof it. Nested subtickets are bounded and validated by the ticket handler before any write. This never executes, sends, publishes, deletes, or mutates an external provider.

  shallow
• ticket_claim

  Claim a ticket to work on: sets assignee to your agent name and moves it to in_progress in one step (the move is audit-logged). Refuses if another agent already has it in progress unless force=true. Follow up with ticket_comment progress updates and finish via ticket_update status='done'.

  shallow
• ticket_comment

  Add a comment to an owned ticket's activity trail. Use kind='progress' for work updates while a ticket is in progress. The authenticated API-key UUID is stamped as author; callers cannot supply or spoof it. Open the comment in plain language before any technical detail — these are read during escalations by people who were not part of the work.

  shallow
• ticket_comments

  Read complete discussion bodies, authors, kinds and timestamps for one owned ticket, including archived tickets. Returns a JSON page, newest first with legacy null times last. limit is 1–100 (default 50). Continue with next_cursor while has_more; reached_oldest means there are no older rows. Cursors are bound to this account/ticket and expire after 24 hours. Omit cursor for a fresh read of newer activity. This is ordinary discussion, not completion evidence or permission to act. Requires tickets:read.

  shallow
• ticket_create

  Create a ticket on the caller's board — optionally as a subticket via parent_id. Recommend degree of difficulty with effort (trivial|small|medium|large|epic) and the kind of work with action_type (strategy|implementation|research|validation|testing|coordination). The authenticated API-key UUID is stamped by the server as creator provenance; callers cannot supply or spoof it. Session/workflow ids are opaque metadata links only. New epics cannot be created already done.

  shallow
• ticket_dependency_add

  Record that an owned ticket cannot complete until another owned ticket is done. The edge is never erased: correct a mistake with ticket_dependency_remove, which marks the edge removed and appends to a ledger rather than deleting anything. Re-adding the same prerequisite reinstates that original edge instead of creating a second one, so an edge removed and restored says so. An edge stops blocking when the prerequisite reaches done, and only then — archiving the prerequisite does not release it. Only epics are gated, so an edge on a task is recorded and reported but never blocks its completion. Rejections carry a stable code: dependency_self (422), dependency_duplicate, dependency_cycle, dependency_graph_too_large (409), ticket_not_found (404).

  shallow
• ticket_dependency_list

  List the prerequisites an owned ticket waits on. Read-only. Each edge reports satisfied, which is true only when the prerequisite is done, plus active/removed_at/removed_by_actor. Removed edges are omitted unless include_removed is true; they never gate completion, and are readable as history.

  shallow
• ticket_dependency_remove

  Stop an owned ticket from waiting on a prerequisite. Removing the last unsatisfied edge can allow this ticket to close, so this is a gate-opening action. Nothing is deleted: the edge is retained, marked with who removed it and when, and the removal is appended to a ledger that survives everything after it. This is not a way to say the prerequisite work is finished — that remains a separate statement about that ticket. Removal is allowed even when either ticket is archived. Rejections carry a stable code: dependency_not_found (404), dependency_already_removed (409).

  shallow
• ticket_get

  Full detail for one owned ticket: description, acceptance criteria, subticket progress, and the recent activity/comment trail. ticket_id is required.

  shallow
• ticket_integration_catalog

  Read source-defined ticket integration capabilities and limitations. Public; no credentials, account state or provider requests. This versioned catalog does not check live deployment, connection health, permissions or readiness.

  shallow
• ticket_label_archive

  Hide an owned label from default suggestions without deleting its identity, assignments or history. Restore it with ticket_label_update archived=false. No ticket lifecycle, provider or permission change.

  shallow
• ticket_label_list

  List the private owner label catalog with retained assignment counts and separate non-archived open counts. Labels are metadata, never approval, priority, severity, assignee, readiness or access authority. No provider label writes.

  shallow
• ticket_label_update

  Edit color, description, group or archived state of an owned label. Explicit null clears optional metadata; identity and assigned ticket strings/history stay unchanged. Supply at least one metadata field. Archiving hides the suggestion but does not remove existing assignments.

  shallow
• ticket_label_upsert

  Create or restore an owner-private label by normalized name. Canonical aliases retain the first display name and identity. Optional metadata updates do not assign it to tickets or change any authority. No provider label writes.

  shallow
• ticket_list

  Page through the caller's tickets on the Meta Council board. The opaque next_cursor is owner- and filter-bound; keep every filter unchanged on the next call. Immutable cursor ordering keeps a stable full-board traversal exact while returned tickets are edited or reordered. Filter by status, assignee, action_type, priority, parent_id (a ticket UUID, or 'none' for root tickets only), or free-text q over title/description. With recursive=true, parent_id must be an owned UUID and all descendants (not the anchor) are returned as one flat, cycle-safe traversal. Session/workflow links are opaque metadata filters, not access grants. Start here to find work, then use ticket_get for detail and ticket_claim to take a ticket.

  shallow
• ticket_plan

  Preview or idempotently commit an owner-private ticket tree generated from a planning prompt or supplied structured plan. Requires tickets:write. A preview without a supplied plan invokes the planner model and additionally requires councils:run; supplied-plan preview and commit are provider-free and need only tickets:write. Preview is non-mutating and returns the normalized commit payload, an exact preview_token, and deterministic predicted ticket IDs as JSON. To commit, combine that commit_payload with mode=commit, the caller-held idempotency_key, and that exact preview_token; the response returns the same IDs plus replay status. A caller-stable visible-ASCII idempotency_key is always required. This creates only in-platform planning tickets; it never runs them, sends, publishes, deletes, or changes an external provider.

  shallow
• ticket_readiness

  Explain why an owned ticket is not ready to close, using the same readiness check as the browser. Returns gated, ready, and the complete bounded blocker list with each code, reference_id and message. An unready ticket is a successful diagnostic, not a tool failure. This snapshot does not authorize completion or change tickets, scenarios, evidence or validation-attempt budgets. Requires authentication and tickets:read; tickets:write also permits reading.

  shallow
• ticket_scenario_create

  Author one Given/When/Then scenario on an owned ticket. This is the specification an epic must carry before it can be completed: record a passing run against it with ticket_validation_finalize, then transition the epic. The server owns revision 1 and returns current_version and current_definition_hash — pass those exact values to ticket_validation_finalize. Authoring a scenario is not evidence; it states what must be proven, not that it was.

  shallow
• ticket_scenario_list

  List an owned ticket's scenarios with their exact current revisions, including the current_version and current_definition_hash that ticket_validation_finalize requires. Read-only. Use it before recording a run to confirm which revision is current, and to see why an epic still reports required_scenario_missing.

  shallow
• ticket_scenario_revise

  Replace an owned scenario's content, compare-and-swapping on expected_version. Revisions are append-only: validation runs already recorded keep naming the exact version and hash they were proven against, so revising never rewrites past evidence — it does mean the epic needs a fresh passing run against the new version. A stale expected_version conflicts rather than overwriting a concurrent edit.

  shallow
• ticket_transition

  Change an owned ticket's status through the existing lifecycle gate. For an epic completion, persist completion_idempotency_key before calling and retry the same request after an uncertain response. Reopening a terminal epic requires the exact expected_completed_at and, for an attested completion, expected_completion_record_id from ticket_authority. Stale coordinates and unready completions refuse without changing status. Reconcile uncertain reopen responses with ticket_authority. Returns committed transition and ticket JSON. Requires tickets:write.

  shallow
• ticket_update

  Update fields on an owned ticket — status moves (each one is auto-logged to the ticket's audit trail), reassignment, priority/effort/action_type recommendations, title/description edits, safe reparenting, opaque session/workflow links, effort points, order, and user-owned external refs. Clear flags are explicit so stdio clients never lose JSON nulls. System-owned provider, Accounting, plan, and batch refs are preserved and cannot be spoofed. The authenticated API-key UUID is stamped on the audit trail. Epic completion and terminal reopen fail closed on this generic tool until an explicit lifecycle operation supplies retry/version evidence.

  shallow
• ticket_validation_finalize

  Finalize one immutable validation run for an exact owned ticket scenario revision. Requires the opt-in tickets:validate scope. The server derives owner and actor only from the authenticated API key. Evidence payloads are bounded opaque JSON objects; locator-looking strings are recorded but never opened, resolved, redirected, or fetched. Exact retries by the same credential actor return the original receipt; a changed actor or changed content under the same key conflicts.

  shallow
• triage_meta_council_feedback

  ADMIN ONLY: triage a platform-feedback report — set its status and/or admin notes (requires an ADMIN_EMAILS account; everyone else gets a permission error). Get the full feedback id from list_meta_council_feedback.

  shallow
• unshare_saved_view

  Make one of YOUR OWN shared saved views private again. Idempotent. Revocation is immediate: team membership is resolved on every read and never copied into a grant, so this takes effect on each member's next request. Requires authentication and the tickets:write scope.

  shallow
• update_consulting_client

  Update mutable fields on an owned consulting client.

  shallow
• update_consulting_deliverable

  Edit an internal draft deliverable; review/approval state is separate.

  shallow
• update_consulting_document_revision

  Edit an unapproved proposal/SOW revision; approved revisions are immutable.

  shallow
• update_consulting_engagement

  Update mutable fields on an owned consulting engagement.

  shallow
• update_consulting_milestone

  Update an owned consulting milestone while preserving its stable ref.

  shallow
• update_content_asset

  Edit an owned draft. Submitted/approved/rejected revisions are immutable and must be revised.

  shallow
• update_deal

  Update one of the caller's deals — most commonly to ADVANCE its stage (e.g. discovery -> proposal). Moving to closed_won/closed_lost stamps the close date; reopening to an open stage clears it. Only the fields you pass change; deal_id is required.

  shallow
• update_invoice

  Update a draft or sent invoice's header fields (client, terms, due date, tax rate, notes). Only the fields you pass change. Blocked once paid/void — void and re-issue instead. invoice_id is required.

  shallow
• update_marketing_audience

  Update fields on one owned audience definition. No delete is exposed over MCP.

  shallow
• update_marketing_brand

  Update fields on one owned brand identity. No delete is exposed over MCP.

  shallow
• update_marketing_campaign

  Update one owned marketing campaign. Campaign status never publishes content.

  shallow
• update_outreach_lead_status

  Advance a lead through the pipeline — set its status / pipeline stage and, optionally, a recorded reply, pitch, or notes. The core pipeline-drive action. Idempotent (setting the same status twice is a no-op). Requires authentication.

  shallow
• update_portfolio_schedule

  Replace the full definition of an owned report schedule using its current expected_revision. Preserve project_id from project_list when retaining project scope; omission or null selects portfolio scope. Pause with enabled=false; archive also disables, and restore paused. Editing an enabled schedule starts at its next future occurrence. Reuse the exact request_id and request for recovery; an exact retry returns the original receipt, so read current state afterward. Requires tickets:write.

  shallow
• update_saved_view

  Revise one of YOUR OWN saved views in place, keeping its id and any existing team share. Only the fields you send change; the rest are left exactly as they were, so this is safe to call without re-reading the whole definition first. Sharing a view does not let its readers revise it -- only the owner may. Requires authentication and the tickets:write scope.

  shallow
• update_workflow_template

  Replace an existing custom workflow template's definition. This is a full replacement, not a patch: supply name and steps as you want them to end up, because anything omitted is not carried over. Built-in templates are read-only, and only the template's owner may change it. Steps run sequentially in the order given; depends_on is builder metadata only and does not change execution order. Requires authentication and the workflows:write scope.

  shallow
• void_invoice

  Void a draft or sent invoice. Cannot be applied to an already-paid invoice (issue a credit note instead). invoice_id is required. No delete tool is exposed over MCP — void is the terminal non-destructive state.

  shallow

Embed this server’s score

Tool count and median score across every tool in this server’s corpus — honest in a way a single cherry-picked tool’s badge wouldn’t be.

[![Vouch score](https://vouch.tools/api/servers/a6052de0-ba23-4f79-b5e5-da7e3dbb29e0/badge.svg)](https://vouch.tools/servers/a6052de0-ba23-4f79-b5e5-da7e3dbb29e0)