Name: Aurgus
Author: aurgus

Aurgus MCP

Governed rebate & revenue close (ASC 606/705/842): explain, ingest, compute, trace to source.

Tool-list grade A Remote · Streamable HTTP No auth needed 38 tools v1.0.0

No reviews yet by aurgus The publisher’s own endpoint — this marketplace is not in the path

93/100

tool-list score

tools declared

remote

at its publisher

—

calls last 7d

What it does

Governed rebate & revenue close (ASC 606/705/842): explain, ingest, compute, trace to source.

Quickstart

# 1 — add it to Claude Code
claude mcp add --scope user --transport http aurgus-mcp https://mcp.aurgus.com/api/mcp

# 2 — ask your agent for something these tools do
#   begin, help, release_notes and 35 more

Aurgus costs nothing on mcprush: there is no plan to choose here, no cap to set and nothing mcprush can bill you for.

Publishernot claimed

aurgus1 server

1 category

All 1 server

Collected from a public index. Nobody has claimed this account, so nothing here was written by its author — claim it if it is yours.

Tool surface

What the model actually sees. Descriptions are diffed on every release — see version history.

Only tools that write or reach the network

Call this the moment the user greets Aurgus or wants to start — 'Aurgus, hi', 'hello', 'hey Aurgus', 'let's start', 'I want to run a close', 'where do I begin'. Aurgus introduces itself as the client's independent revenue-management controller and LEADS into the engagement, asking who the client is, the period, and what's being closed. Free, no account needed, computes nothing — the next step is o

Parameter	Type	Required	Notes
scenario	string	no	Optional: what the user wants to close, if they said (woven into the greeting).

Call this when the user asks for help or how to use Aurgus — 'Aurgus help', 'help', 'what can you do', 'how do I use this', 'show me the manual', 'what are the commands / trigger words'. Returns the Aurgus manual: what it is, how an engagement runs step by step, the trigger phrases that fire each tool, and how to start. Free, no account needed.

No parameter schema on file.

What's new in Aurgus and how to stress-test it — call this for 'what changed', 'release notes', 'what's new', 'changelog', or if you're reviewing/pressure-testing the product. Returns the current release summary (reuse-first institutional knowledge, document/PDF intake, the anti-hallucination guards, ASC coverage) plus a concrete test checklist. Free, no account needed, reads nothing from any tena

No parameter schema on file.

State the governed US-GAAP treatment FOR A PAYMENT TYPE — a rebate, incentive, chargeback, or trade-spend payment — under ASC 606 (customer rebate / consideration payable to a customer / variable consideration), ASC 705-20 (vendor rebate), or ASC 340-40 (sales commission). It CLASSIFIES the payment and returns the governed treatment, the exact ASC citation, and the rule applied — deterministic and

Parameter	Type	Required	Notes
payment	string	no	The nature of the payment. customer_rebate = you pay/credit your customer (sell side); spa_or_billback = a special pricing agreement / billback credit to the customer; chargeback = a channel chargebac
buys_distinct_good_or_service	boolean	no	True if the payment is in exchange for a distinct good or service the counterparty actually transfers (e.g. advertising, data, slotting with proof-of-performance), as opposed to a plain price concessi
fair_value_cap_usd	number	no	Required only when buys_distinct_good_or_service is true: the fair value of that distinct good/service. The payment is a purchase only up to fair value; any excess reverts to the default treatment.
scenario	string	no	Optional free-text description of the user's scenario, for context.

Get the link to run a real close on your OWN numbers — bring a rebate / SPA / deduction extract and get back audit-defensible accruals, full lineage, and an auditor-ready export, with nothing posted to your GL. Use this when the user is ready to move from a sample to their own data. Optionally takes a work email to set up access — only what the user volunteers, and never ask for financial data ins

Parameter	Type	Required	Notes
email	string	no	Optional work email to set up access / follow up. Only pass what the user volunteers.
scenario	string	no	Optional short description of what the user wants to run.

THE one way to talk to Aurgus — the client's revenue-management controller. For ANYTHING the user says to Aurgus (a greeting, 'close Q3', 'where are we', 'what do you need from me'), call THIS with their message rather than picking a specific tool; Aurgus reads the engagement's real state, leads like a firm, and tells you the single next step. Pass entity/period/program when the user has named the

Parameter	Type	Required	Notes
message	string	no	What the user said to Aurgus, verbatim.
engagement_id	string	no	The current engagement, once one is open.
entity	string	no	The client entity, when the user has named who they're closing for.
period	string	no	The close period, when named (e.g. 'Q3 2026').
program	string	no	The program being closed, when named (e.g. 'tiered volume rebate').
who_certifies	string	no	Who will certify the terms + mapping (name or email), when the user has named them — captured at open so the certifier is on the engagement from the start.
direction	string	no	Which side the client is on for a billback / chargeback / rebate: 'paying' (sell-side → ASC 606, reduces revenue) or 'receiving' (buy-side → ASC 705-20, reduces cost of sales). Pass it once the user s

Open a revenue-management engagement for a client. Capture the intake — the client entity, the period, the program(s), the sources of truth, and who will certify — and start the engagement file (a hash-chained, append-only record of everything that follows). This is how a firm begins: a named client and a scope, before any numbers. The agreement comes next; nothing is computed here.

Parameter	Type	Required	Notes
entity	string	yes	The client entity we're closing for (e.g. 'Acme Distribution').
period	string	no	The close period (e.g. 'Q3 2026').
programs	array	no	The rebate / SPA / billback program(s) in scope, if known.
sources_of_truth	array	no	The client's systems of record for this close.
who_certifies	string	no	Who on the client side will certify the terms and mapping (name or email).
direction	string	no	Which side the client is on for a billback / chargeback / rebate: 'paying' (sell-side → ASC 606) or 'receiving' (buy-side → ASC 705-20). Omit if not yet known — Aurgus will ask rather than assume the

Report where an engagement stands — derived from the engagement file's real events, not a stored status. With an engagement id, it shows which steps are on the chain, what's next, and any open items (the close can't be signed while any remain). With no id, it lists the client's engagements and the firm's own status. If the file's hash chain fails re-verification it refuses to report rather than vo

Parameter	Type	Required	Notes
engagement_id	string	no	The engagement to report on. Omit to list all engagements + the firm status.

Draft the PBC (prepared-by-client) document list for an engagement, FROM its agreement — the program decides which files the close needs (a sell-side rebate → the POS / sell-through extract; a buy-side billback → the claims file), never a generic ask. Each requested document is logged as an open item; the close can't be signed until every one is received, mapped and certified. Needs an active agre

Parameter	Type	Required	Notes
engagement_id	string	yes	The engagement to draft the PBC list for.

The engagement's open-items register — the things the close can't yet account for (a document not received, a term not found in the agreement, an unmatched figure). List them, open a new one, or resolve one by id. The register ships alongside the certified figures; no gap is ever filled on the client's behalf, and the close cannot be signed while any item remains open.

Parameter	Type	Required	Notes
engagement_id	string	yes	The engagement whose register to act on.
action	string	no	list (default), open a new item, or resolve one.
item	string	no	For action=open: the open item's description.
owner	string	no	For action=open: who owns resolving it.
item_id	string	no	For action=resolve: the id of the item being resolved.

Receive a client document into an engagement BY REFERENCE — a client-granted signed https link (or an upload handle), never the file's contents. The engine fetches it server-side, stages it inside the client's tenant for certification, and tells you only the column names and where to certify the mapping — no row of the client's data ever passes through the model. Resolves the matching PBC open ite

Parameter	Type	Required	Notes
engagement_id	string	yes	The engagement this document belongs to.
kind	string	yes	Which stream this is (pos = sell-through, claims = billbacks, credits = credit memos).
signed_url	string	no	A client-granted signed https link to the file (e.g. a Drive/SharePoint export). The engine fetches it directly; you do NOT paste the file contents.
upload_handle	string	no	Alternatively, a handle to a file already uploaded to the client's tenant store.

Compute a sales-commission engagement under ASC 340-40 (incremental cost to obtain a contract). Give the commission amount, the benefit period it amortizes over, and how many months have elapsed; it classifies the cost, then capitalizes a recoverable commission and amortizes it straight-line — returning the capitalized asset, amortization to date, the period expense, and the net carrying amount. T

Parameter	Type	Required	Notes
engagement_id	string	yes	The commission engagement (opened via open_engagement, classified as a commission).
commission_usd	number	yes	The commission — the incremental cost to obtain the contract.
benefit_months	number	yes	The benefit period over which it amortizes, in months.
months_elapsed	number	yes	Months elapsed into the benefit period at this close.
expected_to_be_recovered	boolean	no	Whether the cost is expected to be recovered (340-40-25-1). Omit if unknown and it will ask.
elect_practical_expedient	boolean	no	Set true ONLY if the entity has ELECTED the ≤1-year practical expedient (340-40-25-4) to expense a commission that amortizes within a year. Omit/false → a ≤12-month commission CAPITALIZES (25-1); the
contract_terminated	boolean	no	Set true if the underlying contract was TERMINATED early. The remaining capitalized asset can't simply finish amortizing — it triggers an ASC 340-40-35-3 impairment assessment, raised as an open item
remaining_consideration_usd	number	no	On a terminated contract, the consideration the entity still expects to receive (340-40-35-3(a)). Omit if none/unknown and the full carrying amount is flagged for impairment review.

Run the full ASC 606 five-step recognition for a general revenue contract: identify the performance obligations (Step 2), allocate the transaction price by standalone selling price (Step 4), and recognize over time or at a point in time (Step 5). Give the transaction price and the promised items (each with its standalone selling price). Whatever the engine can't determine from what you provide — d

Parameter	Type	Required	Notes
engagement_id	string	yes	The revenue-contract engagement (opened + classified as a general revenue contract).
transaction_price_usd	number	yes	The contract's transaction price.
items	array	yes	The promised items in the contract.

Measure a lease under ASC 842 (v1: the lessee side — real estate and equipment). Give the term, the CERTIFIED discount rate (the rate implicit in the lease, or the incremental borrowing rate — it will NOT assume one), and the payment schedule; it measures the lease liability (present value of the payments), the right-of-use asset (liability + initial direct costs − incentives), and the amortizatio

Parameter	Type	Required	Notes
engagement_id	string	yes	The lease engagement (opened via open_engagement, classified as a lease).
term_periods	number	yes	The lease term as a number of periods.
periods_per_year	number	no	Periods per year: 12 monthly (default), 4 quarterly, 1 annual.
annual_discount_rate_pct	number	yes	The CERTIFIED annual discount rate (%). Omit and it will ask — it never assumes a rate.
payments	array	yes	The lease payment schedule.
incentives_usd	number	no	Lease incentives received (e.g. a tenant-improvement allowance) — reduces the ROU asset.
initial_direct_costs_usd	number	no	Initial direct costs — added to the ROU asset.
prepaid_usd	number	no	Payments made at or before commencement — added to the ROU asset.
payment_timing	string	no	Whether payments fall at period end (arrears, default) or start (advance).
classification	string	no	The certified classification. Omit to default to operating (the v1 real-estate wedge).
party	string	no	v1 is lessee-only; a lessor request is deferred to v2.

Split a trade-spend payment to a customer (co-op advertising, MDF, slotting, listing allowance) under ASC 606-10-32-26 / 705-20-25-2. If the payment buys a DISTINCT good or service the customer actually provides (e.g. advertising with proof-of-performance), it's a purchase/expense UP TO that good's fair value; any EXCESS over fair value reduces revenue. Give the payment amount, whether it buys a d

Parameter	Type	Required	Notes
payment_usd	number	yes	The trade-spend payment to the customer.
buys_distinct_good_or_service	boolean	no	True if the customer transfers a distinct good/service (e.g. advertising with proof-of-performance). False → the whole payment reduces revenue (no split).
fair_value_usd	number	no	Fair value of that distinct good/service. Required to split; omit and it will ask.

A principal signs the governed close for an engagement, by name, on the engagement file. It refuses while any open item remains — the open-items register gates the signature — and a close must have been computed. You cannot sign on the client's behalf; the person signs. Signing is what releases the workpapers.

Parameter	Type	Required	Notes
engagement_id	string	yes	The engagement whose close is being signed.

Deliver the engagement workpapers — the certified figures and the open-items register on one page, from the hash-chained engagement file. Refuses until a principal has signed the close. This is the auditor-ready deliverable: what was concluded, and what could not be proven, together.

Parameter	Type	Required	Notes
engagement_id	string	yes	The engagement to deliver workpapers for.

Hand Aurgus your rebate agreement — PASTE its text, or DROP a PDF/scanned document (pass it as file_base64). Aurgus reads the terms with its deterministic parser (and CV/OCR for a PDF/scan — a Python CPU service, ZERO LLM): customer, basis (whole-volume / incremental / cliff), rate or tier ladder, and the rebate period. A CPU parser proposes spans, deterministic rules produce every value, and anyt

Parameter	Type	Required	Notes
text	string	no	The agreement's text (paste the full agreement, or the rebate clauses). Provide this OR file_base64.
file_base64	string	no	A PDF or scanned-image agreement, base64-encoded. Aurgus reads it with CV/OCR (zero LLM). Provide this OR text.
filename	string	no	The original filename (e.g. 'rebate-agreement.pdf') — used to sniff the file type and shown on the review page.

Build a rebate/incentive agreement by talking it through — no document needed. Describe the program in plain words and Aurgus DRAFTS the terms (who qualifies, how volume is measured and over what period, the threshold, the rate or per-unit reward, any cap, and approval routing) and asks the consultant-style questions a controller would ask before assuming. IMPORTANT: these terms are DRAFTED by the

Parameter	Type	Required	Notes
description	string	yes	Plain-language description of the program — who it's for, how it's measured and over what period, the rate/threshold/cap, the dates. On the first turn, just describe it.
clarifications	array	no	Answers to the follow-up questions from a previous turn, so the draft refines. Each item pairs the question asked with the answer.
finalize	boolean	no	Set true ONLY after the terms have been reviewed and the follow-ups resolved. Stages the proposal for human approval; omit/false to just draft and refine.
proposal	object	no	Required when finalize=true: the EXACT drafted proposal returned by a prior (non-finalize) call, echoed back verbatim — so what is staged is exactly what was reviewed. Staging does NOT re-run the mode

Hand Aurgus one of your three rebate files (CSV) to read into your tenant: 'pos' (your POS / sell-through extract — what was earned), 'claims' (the claims you submitted), or 'credits' (credit memos / vendor invoices you received). Give it the raw CSV, which kind of file it is, and a note of which of your columns maps to which Aurgus field. Rows with blank or bad amounts are held and reported back

Parameter	Type	Required	Notes
csv	string	yes	The raw CSV content of your extract (header row + data rows).
kind	string	no	Which file this is: 'pos' (sales/POS extract — earned), 'claims' (claims submitted), or 'credits' (credit memos / vendor invoices received). Defaults to 'pos'.
mapping	object	yes	Map each of your column headers to an Aurgus field. pos fields: source_transaction_id, transaction_at, end_customer_id, material_id, amount_usd, distributor_id, quantity. claims fields: source_claim_i
filename	string	no	Optional original filename.

The RUN step (step 6) of an open engagement — work the governed, deterministic earned → settled → open accrual across the engagement's active agreements and certified data. Do NOT call this as the first thing when a user says 'compute the close': a firm opens the engagement first (open_engagement), establishes the agreement, requests + certifies the data, and only then runs. If no engagement is op

No parameter schema on file.

Record the human's answer to a customer-grouping question Aurgus asked — a grouping compute_close PROPOSED ('GPG LLC resembles Global Procurement Group LLC', or 'these are the GPO's members'), OR a change to a roster Aurgus already knows ('did anything change?' → a new member joined, or one left). Aurgus never changes a group on its own — this tool is the person's approval, and what makes Aurgus r

Parameter	Type	Required	Notes
agreement_id	string	yes	The agreement whose customer scope this concerns — from the compute_close proposal or roster.
members	array	no	Name(s) the user confirmed BELONG to this agreement (added as members), exactly as they appear in the data.
ended_members	array	no	Member(s) that LEFT the group — their membership is ended as-of valid_to (not deleted; prior purchases stay attributed).

The portfolio report — every active agreement on the tenant (or one, by id), with its earned / settled / open accrual, basis, status, and when it last calculated. This is the book-at-a-glance a controller watches: which agreements are live, what each has earned vs paid out, and what is open. Pass agreement_id for a single agreement, or status to filter the list (active / draft / closed / supersede

Parameter	Type	Required	Notes
agreement_id	string	no	Report on ONE agreement by id. Omit for the whole book.
status	string	no	Filter the list by lifecycle status. Default: active.

Set how often an agreement ACCRUES and SETTLES. Ask the user these when setting an agreement up (or to change them later): (1) how often to accrue — 'realtime' as sales land, or batched 'daily' / 'weekly' / 'monthly' / 'per_event'; (2) how often it settles — when the money actually hits their account — 'weekly', 'semi_monthly', 'monthly', 'quarterly', 'semi_annual', 'annual', 'threshold' (when a d

Parameter	Type	Required	Notes
agreement_id	string	yes	The agreement whose cadence to set.
accrual_cadence	string	no	How often to accrue. 'realtime' = as each sale lands.
settlement_cadence	string	no	How often it settles — when the rebate is actually paid out.
settlement_approver_email	string	no	If someone must APPROVE each settlement before money moves, their email. Aurgus holds every settlement and emails them a one-time confirm link; nothing settles until they approve. Pass an empty string

Close an agreement for good — the terminal true-up at the END of its life (its term ended, or it's being wound down). Closing posts a final true-up Adjustment that matches the accrual to the settled amount (open → $0), THEN FREEZES the agreement: it moves to 'closed' and NO new transactions ever calculate against it again. This is NOT the periodic run (compute_close) or the periodic payout (settle

Parameter	Type	Required	Notes
agreement_id	string	yes	The agreement to close (terminal).
confirm	boolean	no	Omit/false to DRY-RUN (preview the terminal true-up + freeze); true to post the Adjustment and close.
force	boolean	no	Administrative close flag, recorded on the audit trail (the true-up always resolves the open balance regardless).
reason	string	no	Why it's being closed — recorded on the audit trail.

Retire a WRONG agreement that has already accrued — reverse its postings, then archive it. Voiding alone only stops FUTURE accruals; this UNWINDS what already accrued by appending a Reversal for every earning event (earned → $0, strictly append-only — the originals AND the reversals both stay on the ledger for audit), then voids the agreement. Call WITHOUT confirm first to DRY-RUN — it reports how

Parameter	Type	Required	Notes
agreement_id	string	yes	The agreement to reverse & defunct.
confirm	boolean	no	Omit/false to DRY-RUN (preview the reversal); true to actually reverse the postings and archive the agreement.

True-up an agreement — AFTER a settlement, match the accrual account to what was ACTUALLY settled. Posts ONE Adjustment (signed = settled − earned) in the CURRENT period so earned equals settled and the open balance nets to $0. Over-accrued → a negative Adjustment; under-accrued → a positive one. Always current-period, never backdated. Append-only and idempotent (a second run finds it already matc

Parameter	Type	Required	Notes
agreement_id	string	yes	The agreement to true up.
confirm	boolean	no	Omit/false to DRY-RUN (preview the Adjustment); true to post it.

Change the RATES on a rate-routed (dimension-routed) agreement — a regime's flat rate, a tiered regime's own ladder, or the shared tier ladder. Rates are given in PERCENT (1.5 = 1.5%); thresholds in dollars. Call WITHOUT confirm first to DRY-RUN: with no edits it LISTS the current regimes (their keys + rates) so you know what to change; with edits it echoes the intended change. Call again with con

Parameter	Type	Required	Notes
agreement_id	string	yes	The rate-routed agreement to edit.
regimes	array	no	Per-regime rate edits, keyed by the regime's key (from the dry-run list). Give flat_rate_pct for a flat regime, or tiers for a tiered regime's own ladder.
shared_tier_grid	array	no	The shared tier ladder (used by tiered regimes that tier on the whole book). Thresholds in dollars, rate in percent.
confirm	boolean	no	Omit/false to DRY-RUN (list current rates or echo the change); true to apply and raise the gated Recalculate card.

Change an agreement's TERMS — its name, the counterparty (customer_name), the direction (payable_sell_side = you pay a rebate / receivable_buy_side = you earn one), the validity window (valid_from / valid_to, YYYY-MM-DD; pass valid_to:null for open-ended), or the accrual / settlement cadence. Send only the fields to change. This runs the SAME governed core as the workspace edit form (one implement

Parameter	Type	Required	Notes
agreement_id	string	yes	The agreement to edit.
name	string	no	New agreement name.
customer_name	string	no	New counterparty / customer name.
direction	string	no	payable_sell_side (you pay the rebate) or receivable_buy_side (you earn it). Posting-locked once a document is posted to the ERP.
valid_from	string	no	New validity start, YYYY-MM-DD (bare calendar date).
valid_to	string/null	no	New validity end, YYYY-MM-DD, or null for open-ended. A validity change raises a gated Recalculate card.
accrual_cadence	string	no	How often to accrue: realtime \| daily \| weekly \| monthly \| per_event.
settlement_cadence	string	no	How often it settles: weekly \| semi_monthly \| monthly \| quarterly \| semi_annual \| annual \| threshold \| ad_hoc.

Build a GOVERNED analytics report over the rebate data. Pick a MEASURE and GROUP it BY a dimension — the report is composed from a fixed semantic layer (no raw SQL), so it's deterministic, read-only, and ties to the ledger (accrued uses the SAME earned formula as the money path). measure: 'accrued' (earned rebate), 'settled' (paid), 'basis' (transaction amount), or 'count' (events). group_by: 'agr

Parameter	Type	Required	Notes
measure	string	yes	What to measure: accrued (earned) \| settled (paid) \| basis (transaction amount) \| count (events).
group_by	string	yes	How to break it down: agreement \| class (needs dimension_key) \| month \| quarter.
dimension_key	string	no	Required when group_by='class': the declared dimension to group by, e.g. 'interchange_class'.
agreement_id	string	no	Optional — restrict the report to one agreement.

Save an analytics report for reuse. Give it a NAME plus the same measure / group_by (/ dimension_key / agreement_id) you'd pass to analyze — the governed spec is stored under that name (re-saving the same name updates it). Later, run_report re-runs it on current data. Requires a connected Aurgus account.

Parameter	Type	Required	Notes
name	string	yes	A name to save this report under (e.g. 'Rebate by class').
measure	string	yes	accrued \| settled \| basis \| count.
group_by	string	yes	agreement \| class (needs dimension_key) \| month \| quarter.
dimension_key	string	no	Required when group_by='class' — e.g. interchange_class.
agreement_id	string	no	Optional — restrict to one agreement.

List the saved analytics reports on this tenant (name + what each measures). Use run_report with a name to re-run one. Requires a connected Aurgus account.

No parameter schema on file.

Re-run a SAVED analytics report by name on current data — returns the grouped rows + total, governed and read-only exactly like analyze. Requires a connected Aurgus account.

Parameter	Type	Required	Notes
name	string	yes	The saved report's name (see list_reports).

Recalculate — re-run the deterministic engine over the POS data, dispatching every row against the agreement(s) so rows that just became eligible (e.g. after a data fix or a rule change) accrue. Posts provisional accruals (the same engine compute_close uses); rows that already have a positive accrual are skipped (idempotent). Pass agreement_id to recompute ONE agreement, or omit it to recompute AL

Parameter	Type	Required	Notes
agreement_id	string	no	Recompute just this agreement. Omit to recompute all active agreements.

Connect the client's ERP / POS / order system (or Zapier) to Aurgus by creating an API key for their account. This is how transactions flow IN automatically (no CSV uploads) and how Aurgus's journal entries flow OUT to their GL — through the Aurgus Open-API (/api/v1) that the key authenticates. The key carries DATA-INTAKE authorization ONLY: it can push transactions and read the journal/position,

Parameter	Type	Required	Notes
label	string	no	Optional label. Set it ONLY if the user already named one (e.g. 'Zapier'); otherwise OMIT it and do not ask — never block key creation on a label.
confirm	boolean	no	Omit/false to EXPLAIN what will be created and ask; true to actually create the key and return it once.

Settle an agreement — post the PAYOUT. Creates per-bucket Settlement event(s) totalling the open accrual (earned − already settled), moving the open balance to $0. This is the money-OUT step (distinct from compute_close, which accrues, and true_up, which reconciles the accrual to a prior settlement). Call WITHOUT confirm to DRY-RUN — it reports the open accrual that would be paid and any gate that

Parameter	Type	Required	Notes
agreement_id	string	yes	The agreement to settle (pay out its open accrual).
confirm	boolean	no	Omit/false to DRY-RUN (preview the payout + any blocking gate); true to post the Settlement event(s).

Walk any accrued figure all the way back to where it came from — source row → eligibility → bucket → rate → rule → event chain — for a given transaction. This is how you show an auditor exactly why a number is what it is. Requires a connected Aurgus account.

Parameter	Type	Required	Notes
source_transaction_id	string	yes	The transaction id to trace.
agreement_id	string	no	Optional — limit to one agreement; otherwise all agreements that fired on the row.

Put together the auditor-ready package for your tenant: the open accrual you can stand behind (earned → settled → open), where margin is leaking versus what's sitting outside any program, and sample lineage tracing back to source — all computed off the canonical ledger. Requires a connected Aurgus account.

No parameter schema on file.

Free

$0 forever

Every tool — any call limit is its publisher’s, not ours
No card, and mcprush charges nothing for it
Runs at its publisher’s own address — this marketplace is not in the path
Nothing to cap, because mcprush bills nothing

Nothing here is billable: mcprush charges nothing to install Aurgus or to call it, at any volume.

ATool-list grade · score 93 / 100

Release 1.0.0 · scanned 2 Nov 2026

Graded from the tools this server lists, not from its source code.

Two independent axes, because powerful and malicious are different questions. The grade is threat only. The capability level is blast radius, and it is never a penalty on the grade — it is priced as one subtract-only term in the score, where you can see it.

Threat score100

Client score93

Findings0 threat · 0 capability

Capabilitymoderate

Coveragemanifest

Verificationnot in this report

Surface digestb5ebd49f07851f29db01ee3b6c640772b48a5d2f709b8f2862be851e89047edd

Score vectorthreat 100 → client 93

Term	Level	What it prices	Points
capability-exposure	moderate	capability blast radius (moderate) — client exposure if the model is manipulated	−3
coverage-honesty	manifest	inspection depth (manifest) — how much of the target the scan could see	−4

score = clamp(round(threatScore − E_cap − E_ver − E_cov), 0, 100). No model, no opinion, no network call at scoring time: the same methodology version against the same bytes always produces this number, and every line above is a field of the report rather than a summary of it.

What the scan could actually read

A grade is only as meaningful as its coverage, so the scanner publishes its own depth before it publishes its result.

The scan read each tool’s name, description, input schema and annotations exactly as the server listed them the last time it answered us; no code was reviewed. We ask the server again about once a month, and a list that changed is graded again.

Tool surfaceread

Implementation sourcenot available

Package metadatanot available

Live transportnot available

The implementation source was not read — this reflects the declared tool metadata only.

Capability — what it could do if the model were manipulated

Tags derived from each tool’s schema and the implementation, not from what the tool calls itself. moderate is the level these add up to.

Tool	Capability tags	Why the tag was assigned
begin	no tags
help	no tags
release_notes	no tags
explain	no tags
request_real_run	state-write	state-write: declares readOnlyHint: false
aurgus	state-write	state-write: declares readOnlyHint: false
open_engagement	state-write	state-write: declares readOnlyHint: false
engagement_status	no tags
request_documents	state-write	state-write: declares readOnlyHint: false
open_items	state-write	state-write: declares readOnlyHint: false
receive_document	state-write	state-write: declares readOnlyHint: false
compute_commission	state-write	state-write: declares readOnlyHint: false
compute_revenue_contract	state-write	state-write: declares readOnlyHint: false
compute_lease	state-write	state-write: declares readOnlyHint: false
compute_trade_spend	no tags
sign_close	state-write	state-write: declares readOnlyHint: false
export_workpapers	no tags
ingest_agreement	state-write	state-write: declares readOnlyHint: false
compose_agreement	state-write	state-write: declares readOnlyHint: false
ingest	state-write	state-write: declares readOnlyHint: false
compute_close	state-write	state-write: declares readOnlyHint: false
confirm_grouping	state-write	state-write: declares readOnlyHint: false
report	no tags
set_cadence	state-write	state-write: declares readOnlyHint: false
close_agreement	state-write	state-write: declares readOnlyHint: false
defunct_agreement	state-write	state-write: declares readOnlyHint: false, destructiveHint: true
true_up	state-write	state-write: declares readOnlyHint: false
edit_agreement_rates	state-write	state-write: declares readOnlyHint: false
edit_agreement	state-write	state-write: declares readOnlyHint: false
analyze	no tags
save_report	state-write	state-write: declares readOnlyHint: false
list_reports	no tags
run_report	no tags
recalculate	state-write	state-write: declares readOnlyHint: false
connect_integration	state-write	state-write: declares readOnlyHint: false
settle	state-write	state-write: declares readOnlyHint: false
trace	no tags
export	no tags

Toxic-flow graph

The lethal trifecta, checked as a graph rather than as a checklist: untrusted input, a sensitive source and an external sink have to meet before there is a path worth worrying about.

The public result for this release does not print the flow graph, so there is nothing to show here. That is not the same as "no paths were found": what the scan did read is above, under coverage.

Supply chain and provenance

Integrityfirst-seen

Surface digestb5ebd49f07851f29

Scanned2026-11-02

This is the first scan of this surface here, so there is nothing yet to compare it against.

Every result on this tab comes from one deterministic pass over the published package — offline, rule by rule, and auditable line by line above. Same methodology version, same bytes, same score.

Where are you running it?

Tool surface

Release history

Aurgus MCP

What it does

Quickstart

Where are you running it?

Tool surface

What counts against your monthly calls

What the scan could actually read

Capability — what it could do if the model were manipulated

Toxic-flow graph

Supply chain and provenance

Release history

See also