Fund allocator
fund-allocator v1Divides the money set aside for partners by a rule the partners can read and apply to their own numbers. It takes in the approved budget, chooses the rule, says which activities the fund may buy and which it may not, sets the caps and the share each side pays, runs the rule against every partner, and checks the amounts sum to the money that exists. Once the fund is open it holds the balance: it commits money against an approved request, releases what a claim did not use, and moves what will not be spent before the period closes. The point of the job is that a partner can work out the number they were given without asking anybody.
What it is granted, and what it hands to a person
This diagram shows which systems the agent may reach, which processes it works in, and what it hands to a person. Everything drawn here is written down in the document, and an abstract agent is worth having only if both edges of it are.
Convenes decide-and-announce for the allocation rule, the caps and the match, and again when unused money is moved, because every partner has to hear the same rule on the same day. Runs collect-and-report on last period's fund and on what is committed as the period runs. Runs assessment for eligibility and for the balance behind a request. Convenes the debrief that closes a period or a decision. Holds the run-scoped commitment ledger in all three processes. Takes the request in from the partner-manager agent, hands the evidence question to the claim-check agent at approval time, and takes the scored claim back from it before releasing what was not paid.
What is in the package
5 skills and the systems they need, written to version 1.1.0 of the Agent Plugins standard. Nothing in these files names a product. The package says which systems the agent needs and what it does with each one, and you say which of your systems fills each role when you set it up.
# Where this abstract agent stops Does not check the evidence behind a claim, match it to its approval, or score it, which is the claim-check agent. Does not make the payment, which is accounts payable (person); this agent records the payment and draws the fund down against it. Does not set the discount, the margin or the support a tier carries, which is the margin-keeper agent. Does not decide the budget the fund comes from, and does not talk to the partner, which is the partner-manager agent. ## What always goes to a person - money above the threshold - to the person who signs, always, and this agent never signs its own number - a partner with an expired agreement or an unresolved claim asking for an allocation - to whoever clears it, with what is outstanding - unused money as the period nears its close - to the partner lead, with what could still use it and by when - a rule that gives an amount nobody can defend - to the partner lead, with the inputs that produced it - a request the published eligible list does not cover that somebody wants approved anyway, because reinterpreting the list per request is how the list stops meaning anything
# The records this abstract agent must leave
This is the contract. An agent implementing `fund-allocator` leaves the
following behind, on every run.
The allocation rule at a version, with the date it was published and the
date every partner was told. Per partner, the amount and the exact
inputs the rule read to produce it. The eligible activity list at a
version, saying what is excluded as well as what is included. The
amounts summed against the approved budget, and the difference. Per
request: the eligibility finding naming the list version it was scored
against, the balance at the time, the organization's share with the
match and the cap applied, the decision and the reason it rests on. Per
commitment: the amount held, the partner's fund it came from, and the
date it expires. Per release: what went back to the fund and why. At the
period close, what was allocated, committed, claimed, paid, released and
moved. Any auditor can recompute a partner's allocation from the rule
version and the recorded inputs.
An agent that leaves less than this does not implement `fund-allocator`,
whatever else it does well.
# The systems this abstract agent needs
Eight systems, named by role rather than by product. The access level is
the most this work needs, and a deployment that grants more is granting
more than the job requires.
| Role | Access | What the access is for |
|---|---|---|
| the fund record | write | Allocations, commitments and releases live here, and this agent is the only thing that moves the balance. |
| the ledger | write | The signed amounts are opened on the books where claims are paid from. |
| the partner record | read | The tier and the standing the rule reads. |
| the agreement record | read | No money is committed against an agreement that expires before the activity date. |
| the partner portal | write | The rule, the eligible activity list and the deadlines are published where every partner can read them. |
| analytics | read | What each partner delivered, which the rule turns into an amount. |
| the CRM | read | |
| the notification channel | write | |
Whoever builds an agent from this plugin writes the `mcp.json` that
points these roles at their own systems. Nothing here names a product,
so the same package works whatever you already run.
{
"$schema": "https://agent-plugins.org/schemas/1.1.0/plugin.schema.json",
"name": "fund-allocator",
"version": "1.0.0",
"description": "The fund-allocator abstract agent. Divides the money set aside for partners by a rule the partners can read and apply to their own numbers.",
"author": {
"name": "AgentCatalog",
"url": "https://agentcatalog.com"
},
"homepage": "https://agentcatalog.com/abstract-agents/fund-allocator",
"repository": "https://github.com/jeffrschneider/agentcatalog",
"license": "CC-BY-4.0",
"keywords": [
"abstract-agent",
"reference",
"partners",
"allocate-the-fund",
"approve-a-fund-request",
"check-and-pay-a-claim",
"abstract"
],
"extensions": {
"com.agentcatalog.agent": {
"agent": "fund-allocator",
"agentVersion": 1,
"department": "partners",
"abstract": true,
"works": "Convenes decide-and-announce for the allocation rule, the caps and the match, and again when unused money is moved, because every partner has to hear the same rule on the same day. Runs collect-and-report on last period's fund and on what is committed as the period runs. Runs assessment for eligibility and for the balance behind a request. Convenes the debrief that closes a period or a decision. Holds the run-scoped commitment ledger in all three processes. Takes the request in from the partner-manager agent, hands the evidence question to the claim-check agent at approval time, and takes the scored claim back from it before releasing what was not paid.",
"servers": [
{
"name": "the fund record",
"role": "fund-record",
"access": "write",
"needs": "Allocations, commitments and releases live here, and this agent is the only thing that moves the balance."
},
{
"name": "the ledger",
"role": "ledger",
"access": "write",
"needs": "The signed amounts are opened on the books where claims are paid from."
},
{
"name": "the partner record",
"role": "partner-record",
"access": "read",
"needs": "The tier and the standing the rule reads."
},
{
"name": "the agreement record",
"role": "agreement-record",
"access": "read",
"needs": "No money is committed against an agreement that expires before the activity date."
},
{
"name": "the partner portal",
"role": "partner-portal",
"access": "write",
"needs": "The rule, the eligible activity list and the deadlines are published where every partner can read them."
},
{
"name": "analytics",
"role": "analytics",
"access": "read",
"needs": "What each partner delivered, which the rule turns into an amount."
},
{
"name": "the CRM",
"role": "crm",
"access": "read"
},
{
"name": "the notification channel",
"role": "notification-channel",
"access": "write"
}
],
"records": [
"The allocation rule at a version, with the date it was published and the date every partner was told.",
"Per partner, the amount and the exact inputs the rule read to produce it.",
"The eligible activity list at a version, saying what is excluded as well as what is included.",
"The amounts summed against the approved budget, and the difference.",
"Per request: the eligibility finding naming the list version it was scored against, the balance at the time, the organization's share with the match and the cap applied, the decision and the reason it rests on.",
"Per commitment: the amount held, the partner's fund it came from, and the date it expires.",
"Per release: what went back to the fund and why.",
"At the period close, what was allocated, committed, claimed, paid, released and moved.",
"Any auditor can recompute a partner's allocation from the rule version and the recorded inputs."
],
"escalates": [
"money above the threshold - to the person who signs, always, and this agent never signs its own number",
"a partner with an expired agreement or an unresolved claim asking for an allocation - to whoever clears it, with what is outstanding",
"unused money as the period nears its close - to the partner lead, with what could still use it and by when",
"a rule that gives an amount nobody can defend - to the partner lead, with the inputs that produced it",
"a request the published eligible list does not cover that somebody wants approved anyway, because reinterpreting the list per request is how the list stops meaning anything"
],
"not": [
"Does not check the evidence behind a claim, match it to its approval, or score it, which is the claim-check agent.",
"Does not make the payment, which is accounts payable (person); this agent records the payment and draws the fund down against it.",
"Does not set the discount, the margin or the support a tier carries, which is the margin-keeper agent.",
"Does not decide the budget the fund comes from, and does not talk to the partner, which is the partner-manager agent."
],
"processes": [
{
"process": "ref/prt/allocate-the-fund",
"activities": [
"Take in the Approved Budget",
"Read Last Period's Fund",
"Choose the Allocation Rule",
"Set What the Fund May Buy",
"Set the Caps, the Match and the Pool",
"Run the Rule against the Partners",
"Check the Amounts against the Money",
"Open the Fund on the Books",
"Publish the Rules Partners Can Read",
"Watch the Fund as It Is Committed",
"Move Money That Will Not Be Used",
"Record What Was Learned"
]
},
{
"process": "ref/prt/approve-a-fund-request",
"activities": [
"Check the Activity Is Eligible",
"Check the Money Is There",
"Price the Organization's Share",
"Decide the Request",
"Commit the Money",
"Record the Decision"
]
},
{
"process": "ref/prt/check-and-pay-a-claim",
"activities": [
"Check Each Cost Is Eligible",
"Pay the Partner",
"Release the Money Not Used"
]
}
]
}
}
}
# fund-allocator This is an abstract agent, published as an Agent Plugin. An abstract agent is a job description rather than an implementation. It says what the work is, which systems it needs and at what access, what it must leave behind, and where it stops. Any agent that leaves the records can implement it. The plugin carries five skills, no `mcp.json`, and everything the abstract agent owes under `com.agentcatalog.agent/`. ## Why there is no mcp.json A conformant server entry in `mcp.json` has to declare a transport and then either a `command` to launch or a `url` to connect to. An abstract agent has neither, because it does not know which product holds your records. Writing placeholder URLs would produce a plugin that loads and then fails to connect, which is worse than one that says nothing. Section 6.2 makes a missing component location not an error, so the file is absent and the systems this abstract agent needs are declared instead under `extensions["com.agentcatalog.agent"].servers`, as a role, an access level and what the access is for. Whoever builds an agent from this plugin writes the `mcp.json` that points those roles at their own systems, so nothing here depends on a particular supplier. ## Why the obligations are in an extension The specification defines two component types, skills and MCP servers, and both describe what a plugin can do. An abstract agent's contract is mostly the other half: the records it must leave, what it escalates, and what it must not do. There is no portable field for any of that, so it lives in a reverse-domain namespace as section 8 requires, in the manifest and in the directory of the same name. ## Where this abstract agent is used `ref/prt/allocate-the-fund`, `ref/prt/approve-a-fund-request`, `ref/prt/check-and-pay-a-claim`. The list is generated from the activity tables of the processes that name it. https://agentcatalog.com/abstract-agents/fund-allocator
--- name: decide-a-request-against-the-fund description: Scores a request against the published eligible list, checks the balance is there, prices the organization's share with the match and the cap applied, decides it, holds the money against it, and records the decision with the reason it rests on. Use it when running `ref/prt/approve-a-fund-request`. license: CC-BY-4.0 metadata: agent: fund-allocator agent-version: "1" --- # Decide a request against the fund ## What it does Scores a request against the published eligible list, checks the balance is there, prices the organization's share with the match and the cap applied, decides it, holds the money against it, and records the decision with the reason it rests on. ## Where it happens The agent does this in six activities across one reference process. Each one names the activity as that process words it. - **Check the Activity Is Eligible** - `ref/prt/approve-a-fund-request`, activity 4 - [Approve a Fund Request](../../../../processes/partners/approve-a-fund-request.md) - **Check the Money Is There** - `ref/prt/approve-a-fund-request`, activity 5 - [Approve a Fund Request](../../../../processes/partners/approve-a-fund-request.md) - **Commit the Money** - `ref/prt/approve-a-fund-request`, activity 14 - [Approve a Fund Request](../../../../processes/partners/approve-a-fund-request.md) - **Decide the Request** - `ref/prt/approve-a-fund-request`, activity 12 - [Approve a Fund Request](../../../../processes/partners/approve-a-fund-request.md) - **Price the Organization's Share** - `ref/prt/approve-a-fund-request`, activity 10 - [Approve a Fund Request](../../../../processes/partners/approve-a-fund-request.md) - **Record the Decision** - `ref/prt/approve-a-fund-request`, activity 17 - [Approve a Fund Request](../../../../processes/partners/approve-a-fund-request.md) ## What to record The allocation rule at a version, with the date it was published and the date every partner was told. Per partner, the amount and the exact inputs the rule read to produce it. The eligible activity list at a version, saying what is excluded as well as what is included. The amounts summed against the approved budget, and the difference. Per request: the eligibility finding naming the list version it was scored against, the balance at the time, the organization's share with the match and the cap applied, the decision and the reason it rests on. Per commitment: the amount held, the partner's fund it came from, and the date it expires. Per release: what went back to the fund and why. At the period close, what was allocated, committed, claimed, paid, released and moved. Any auditor can recompute a partner's allocation from the rule version and the recorded inputs. That contract covers every activity this abstract agent takes on, and it is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract agent does not do is in `com.agentcatalog.agent/NOT.md`.
--- name: divide-the-money-and-open-the-fund description: Runs the rule against every partner, checks the amounts sum to the money that exists, opens the signed amounts on the books, and publishes the rule, the eligible list and the deadlines where every partner can read them. Use it when running `ref/prt/allocate-the-fund`. license: CC-BY-4.0 metadata: agent: fund-allocator agent-version: "1" --- # Divide the money and open the fund ## What it does Runs the rule against every partner, checks the amounts sum to the money that exists, opens the signed amounts on the books, and publishes the rule, the eligible list and the deadlines where every partner can read them. A partner can then work out its own number without asking anybody. ## Where it happens The agent does this in four activities across one reference process. Each one names the activity as that process words it. - **Check the Amounts against the Money** - `ref/prt/allocate-the-fund`, activity 8 - [Allocate the Fund](../../../../processes/partners/allocate-the-fund.md) - **Open the Fund on the Books** - `ref/prt/allocate-the-fund`, activity 11 - [Allocate the Fund](../../../../processes/partners/allocate-the-fund.md) - **Publish the Rules Partners Can Read** - `ref/prt/allocate-the-fund`, activity 12 - [Allocate the Fund](../../../../processes/partners/allocate-the-fund.md) - **Run the Rule against the Partners** - `ref/prt/allocate-the-fund`, activity 7 - [Allocate the Fund](../../../../processes/partners/allocate-the-fund.md) ## What to record The allocation rule at a version, with the date it was published and the date every partner was told. Per partner, the amount and the exact inputs the rule read to produce it. The eligible activity list at a version, saying what is excluded as well as what is included. The amounts summed against the approved budget, and the difference. Per request: the eligibility finding naming the list version it was scored against, the balance at the time, the organization's share with the match and the cap applied, the decision and the reason it rests on. Per commitment: the amount held, the partner's fund it came from, and the date it expires. Per release: what went back to the fund and why. At the period close, what was allocated, committed, claimed, paid, released and moved. Any auditor can recompute a partner's allocation from the rule version and the recorded inputs. That contract covers every activity this abstract agent takes on, and it is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract agent does not do is in `com.agentcatalog.agent/NOT.md`.
--- name: draw-the-fund-down-against-a-claim description: Scores each claimed cost against the eligible activity list, records the payment and draws the partner's fund down against it, and puts back whatever the claim did not use. Use it when running `ref/prt/check-and-pay-a-claim`. license: CC-BY-4.0 metadata: agent: fund-allocator agent-version: "1" --- # Draw the fund down against a claim ## What it does Scores each claimed cost against the eligible activity list, records the payment and draws the partner's fund down against it, and puts back whatever the claim did not use. ## Where it happens The agent does this in three activities across one reference process. Each one names the activity as that process words it. - **Check Each Cost Is Eligible** - `ref/prt/check-and-pay-a-claim`, activity 5 - [Check and Pay a Claim](../../../../processes/partners/check-and-pay-a-claim.md) - **Pay the Partner** - `ref/prt/check-and-pay-a-claim`, activity 13 - [Check and Pay a Claim](../../../../processes/partners/check-and-pay-a-claim.md) - **Release the Money Not Used** - `ref/prt/check-and-pay-a-claim`, activity 14 - [Check and Pay a Claim](../../../../processes/partners/check-and-pay-a-claim.md) ## What to record The allocation rule at a version, with the date it was published and the date every partner was told. Per partner, the amount and the exact inputs the rule read to produce it. The eligible activity list at a version, saying what is excluded as well as what is included. The amounts summed against the approved budget, and the difference. Per request: the eligibility finding naming the list version it was scored against, the balance at the time, the organization's share with the match and the cap applied, the decision and the reason it rests on. Per commitment: the amount held, the partner's fund it came from, and the date it expires. Per release: what went back to the fund and why. At the period close, what was allocated, committed, claimed, paid, released and moved. Any auditor can recompute a partner's allocation from the rule version and the recorded inputs. That contract covers every activity this abstract agent takes on, and it is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract agent does not do is in `com.agentcatalog.agent/NOT.md`.
--- name: hold-the-fund-through-the-period description: Watches the balance as it is committed, moves money that will not be spent before the period closes and tells every partner the same thing on the same day when it does, and files what the period taught. Use it when running `ref/prt/allocate-the-fund`. license: CC-BY-4.0 metadata: agent: fund-allocator agent-version: "1" --- # Hold the fund through the period ## What it does Watches the balance as it is committed, moves money that will not be spent before the period closes and tells every partner the same thing on the same day when it does, and files what the period taught. ## Where it happens The agent does this in three activities across one reference process. Each one names the activity as that process words it. - **Move Money That Will Not Be Used** - `ref/prt/allocate-the-fund`, activity 15 - [Allocate the Fund](../../../../processes/partners/allocate-the-fund.md) - **Record What Was Learned** - `ref/prt/allocate-the-fund`, activity 17 - [Allocate the Fund](../../../../processes/partners/allocate-the-fund.md) - **Watch the Fund as It Is Committed** - `ref/prt/allocate-the-fund`, activity 14 - [Allocate the Fund](../../../../processes/partners/allocate-the-fund.md) ## What to record The allocation rule at a version, with the date it was published and the date every partner was told. Per partner, the amount and the exact inputs the rule read to produce it. The eligible activity list at a version, saying what is excluded as well as what is included. The amounts summed against the approved budget, and the difference. Per request: the eligibility finding naming the list version it was scored against, the balance at the time, the organization's share with the match and the cap applied, the decision and the reason it rests on. Per commitment: the amount held, the partner's fund it came from, and the date it expires. Per release: what went back to the fund and why. At the period close, what was allocated, committed, claimed, paid, released and moved. Any auditor can recompute a partner's allocation from the rule version and the recorded inputs. That contract covers every activity this abstract agent takes on, and it is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract agent does not do is in `com.agentcatalog.agent/NOT.md`.
--- name: set-the-allocation-rule description: Takes in the approved budget, reads what last period's fund did, and settles the rule the money will be divided by. Use it when running `ref/prt/allocate-the-fund`. license: CC-BY-4.0 metadata: agent: fund-allocator agent-version: "1" --- # Set the allocation rule ## What it does Takes in the approved budget, reads what last period's fund did, and settles the rule the money will be divided by. It says which activities the fund may buy and which it may not, and sets the caps, the share each side pays and any pool held back. ## Where it happens The agent does this in five activities across one reference process. Each one names the activity as that process words it. - **Choose the Allocation Rule** - `ref/prt/allocate-the-fund`, activity 4 - [Allocate the Fund](../../../../processes/partners/allocate-the-fund.md) - **Read Last Period's Fund** - `ref/prt/allocate-the-fund`, activity 2 - [Allocate the Fund](../../../../processes/partners/allocate-the-fund.md) - **Set What the Fund May Buy** - `ref/prt/allocate-the-fund`, activity 5 - [Allocate the Fund](../../../../processes/partners/allocate-the-fund.md) - **Set the Caps, the Match and the Pool** - `ref/prt/allocate-the-fund`, activity 6 - [Allocate the Fund](../../../../processes/partners/allocate-the-fund.md) - **Take in the Approved Budget** - `ref/prt/allocate-the-fund`, activity 1 - [Allocate the Fund](../../../../processes/partners/allocate-the-fund.md) ## What to record The allocation rule at a version, with the date it was published and the date every partner was told. Per partner, the amount and the exact inputs the rule read to produce it. The eligible activity list at a version, saying what is excluded as well as what is included. The amounts summed against the approved budget, and the difference. Per request: the eligibility finding naming the list version it was scored against, the balance at the time, the organization's share with the match and the cap applied, the decision and the reason it rests on. Per commitment: the amount held, the partner's fund it came from, and the date it expires. Per release: what went back to the fund and why. At the period close, what was allocated, committed, claimed, paid, released and moved. Any auditor can recompute a partner's allocation from the rule version and the recorded inputs. That contract covers every activity this abstract agent takes on, and it is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract agent does not do is in `com.agentcatalog.agent/NOT.md`.
Every server entry in an mcp.json needs either a command to run or a url to connect to, and the package cannot know either of those until somebody points it at their own systems. So the file is left out, the systems the agent needs are named by role in plugin.json, and you write the mcp.json when you set it up.
Point it at your systems
To run an agent built from this package, write an mcp.json that says which of your systems fills each role. The package names these 8 roles, and the access level beside each one is the most the work needs.
{
"$schema": "https://agent-plugins.org/schemas/1.1.0/mcp.schema.json",
"mcpServers": {
"fund-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/fund-record"
},
"ledger": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/ledger"
},
"partner-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/partner-record"
},
"agreement-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/agreement-record"
},
"partner-portal": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/partner-portal"
},
"analytics": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/analytics"
},
"crm": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/crm"
},
"notification-channel": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/notification-channel"
}
}
}
The hostnames here are a placeholder for your own. Whichever product holds each of these systems, the agent you build is yours and nobody else has to be involved in running it.
3 processes, 21 activities
The highlighted activities are the ones this abstract agent does. The other activities in each process belong to other abstract agents or to people.
Take in the Approved Budget · Read Last Period's Fund · Choose the Allocation Rule · Set What the Fund May Buy · Set the Caps, the Match and the Pool · Run the Rule against the Partners · Check the Amounts against the Money · Open the Fund on the Books · Publish the Rules Partners Can Read · Watch the Fund as It Is Committed · Move Money That Will Not Be Used · Record What Was Learned
Check the Activity Is Eligible · Check the Money Is There · Price the Organization's Share · Decide the Request · Commit the Money · Record the Decision
Check Each Cost Is Eligible · Pay the Partner · Release the Money Not Used
What it writes down
The allocation rule at a version, with the date it was published and the date every partner was told. Per partner, the amount and the exact inputs the rule read to produce it. The eligible activity list at a version, saying what is excluded as well as what is included. The amounts summed against the approved budget, and the difference. Per request: the eligibility finding naming the list version it was scored against, the balance at the time, the organization's share with the match and the cap applied, the decision and the reason it rests on. Per commitment: the amount held, the partner's fund it came from, and the date it expires. Per release: what went back to the fund and why. At the period close, what was allocated, committed, claimed, paid, released and moved. Any auditor can recompute a partner's allocation from the rule version and the recorded inputs.
What it will not do
Does not check the evidence behind a claim, match it to its approval, or score it, which is the claim-check agent. Does not make the payment, which is accounts payable (person); this agent records the payment and draws the fund down against it. Does not set the discount, the margin or the support a tier carries, which is the margin-keeper agent. Does not decide the budget the fund comes from, and does not talk to the partner, which is the partner-manager agent.
These limits are written into the job on purpose, so that everyone adopting the process knows which decisions stay with a person.
Who has built one, and how far each one got
Nobody has built one yet. The catalog says so rather than leaving the section off, because an empty list is a fact about the document.
implements: fund-allocator v1
One line in your agent's manifest. The catalog checks it against the records your runs actually leave.
The closest things in the catalog, by description
Nobody above has claimed any of these. This is the nearest match by wording between the job written above and what publishers wrote about their own listings, closest first, and wording is not evidence: some of these will be wrong, and a job with nothing suitable still gets whatever was nearest. The publishers have never heard of this abstract agent and have promised nothing about it. What a claim looks like is in the table above, and it is signed.
Not workers. These are capability that whatever does the job would use, which is a different relationship and kept in its own column for that reason.
- Cofferline MCP server · cofferline.com · hosted · mirrored from the MCP registry Treasury and risk controls for agent wallets: policies, quotes, prediction-market orders.
- Budgetary: estimate token spend MCP server · thriftell.github.io · run it yourself · mirrored from the MCP registry Pre-flight token-spend estimate (range, scenario, confidence) for a coding task, or an abstention.
- FinStat MCP server · finstat.ai · hosted · mirrored from the MCP registry Documents in, reconciled double-entry books out. Statements, invoices, receipts, matched and posted.