Claim check
claim-check v1Decides whether a funded activity actually happened as it was approved, and pays or refuses each line with the reason attached. It fixes the evidence list before the money is spent, then checks the claim against that list: every document present, the activity the same one that was approved, each cost eligible, the invoices real, and nothing claimed twice. It scores the claim into pays in full, pays in part or does not pay, and every cut names the rule it fails or the evidence it lacks. The job is the evidence, not the money: what it produces is a finding somebody else can read and act on.
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 at approval time to settle the evidence the claim will have to carry, so the list is agreed with the partner before the money is spent and is not added to afterwards. Runs assessment for every check it makes, one pass per question, each leaving its own finding. Convenes the debrief that says what the checks keep catching. Takes the eligible activity list from the fund-allocator agent and hands the scored claim back to it. Works beside the finance partner (person) on the invoices and the partner lead (person) on any line the rules do not reach.
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 decide whether an activity was worth funding or hold the fund balance, which is the fund-allocator agent, and does not commit, release or pay money. Does not judge whether the activity worked, which is the analytics and partner-monitor agents reading what it produced; this agent only establishes that it happened as approved. Does not ask the partner for what is missing or tell them what was paid, which is the partner-manager agent. Does not write the eligible activity list it scores against. ## What always goes to a person - a line the rules do not reach - to the partner lead, with the evidence and the rules it sits between, rather than being guessed - payment itself, always - a person approves the amount and a person pays it - evidence that looks altered, or a cost claimed under a second programme - with both claims attached and the programme named - a claim that arrived after the deadline that somebody wants paid anyway - a check that keeps catching the same thing across claims, because that is a rule or a form problem rather than a partner problem
# The records this abstract agent must leave
This is the contract. An agent implementing `claim-check` leaves the
following behind, on every run.
Per claim: the approval it was checked against, at its version, and the
evidence list agreed at that approval. The completeness check, naming
every document the approval asked for and whether it arrived. The match
between the activity claimed and the activity approved, on date, place
and scope. Each evidence item marked present, missing or insufficient.
Each cost line scored against the eligible activity list at its version,
with the rule it passes or fails. The invoice check, naming amounts,
dates, tax treatment and who was actually paid. The duplicate check,
naming where else a cost appeared if it did. The score, with the amount
payable, the amount cut, and a reason on every cut. For any line the
rules could not reach, the person who decided it and what they decided.
A run can be replayed line by line from what it left behind.
An agent that leaves less than this does not implement `claim-check`,
whatever else it does well.
# The systems this abstract agent needs
Seven 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 | read | The approval the claim rests on, at the version the approval was given under. |
| the partner record | write | The claim's finding lands against the partner it belongs to. |
| the agreement record | read | |
| the CRM | read | Whether a cost was already carried somewhere else. |
| analytics | read | What the activity was supposed to produce. |
| the partner portal | write | The partner is told what was cut and why, in one list rather than a series of questions. |
| the notification channel | write | |
There is deliberately no grant over the payment system or the fund
balance. This agent says what should be paid; the money moves elsewhere.
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": "claim-check",
"version": "1.0.0",
"description": "The claim-check abstract agent. Decides whether a funded activity actually happened as it was approved, and pays or refuses each line with the reason attached.",
"author": {
"name": "AgentCatalog",
"url": "https://agentcatalog.com"
},
"homepage": "https://agentcatalog.com/abstract-agents/claim-check",
"repository": "https://github.com/jeffrschneider/agentcatalog",
"license": "CC-BY-4.0",
"keywords": [
"abstract-agent",
"reference",
"partners",
"check-and-pay-a-claim",
"approve-a-fund-request",
"abstract"
],
"extensions": {
"com.agentcatalog.agent": {
"agent": "claim-check",
"agentVersion": 1,
"department": "partners",
"abstract": true,
"works": "Convenes decide-and-announce at approval time to settle the evidence the claim will have to carry, so the list is agreed with the partner before the money is spent and is not added to afterwards. Runs assessment for every check it makes, one pass per question, each leaving its own finding. Convenes the debrief that says what the checks keep catching. Takes the eligible activity list from the fund-allocator agent and hands the scored claim back to it. Works beside the finance partner (person) on the invoices and the partner lead (person) on any line the rules do not reach.",
"servers": [
{
"name": "the fund record",
"role": "fund-record",
"access": "read",
"needs": "The approval the claim rests on, at the version the approval was given under."
},
{
"name": "the partner record",
"role": "partner-record",
"access": "write",
"needs": "The claim's finding lands against the partner it belongs to."
},
{
"name": "the agreement record",
"role": "agreement-record",
"access": "read"
},
{
"name": "the CRM",
"role": "crm",
"access": "read",
"needs": "Whether a cost was already carried somewhere else."
},
{
"name": "analytics",
"role": "analytics",
"access": "read",
"needs": "What the activity was supposed to produce."
},
{
"name": "the partner portal",
"role": "partner-portal",
"access": "write",
"needs": "The partner is told what was cut and why, in one list rather than a series of questions."
},
{
"name": "the notification channel",
"role": "notification-channel",
"access": "write"
}
],
"records": [
"Per claim: the approval it was checked against, at its version, and the evidence list agreed at that approval.",
"The completeness check, naming every document the approval asked for and whether it arrived.",
"The match between the activity claimed and the activity approved, on date, place and scope.",
"Each evidence item marked present, missing or insufficient.",
"Each cost line scored against the eligible activity list at its version, with the rule it passes or fails.",
"The invoice check, naming amounts, dates, tax treatment and who was actually paid.",
"The duplicate check, naming where else a cost appeared if it did.",
"The score, with the amount payable, the amount cut, and a reason on every cut.",
"For any line the rules could not reach, the person who decided it and what they decided.",
"A run can be replayed line by line from what it left behind."
],
"escalates": [
"a line the rules do not reach - to the partner lead, with the evidence and the rules it sits between, rather than being guessed",
"payment itself, always - a person approves the amount and a person pays it",
"evidence that looks altered, or a cost claimed under a second programme - with both claims attached and the programme named",
"a claim that arrived after the deadline that somebody wants paid anyway",
"a check that keeps catching the same thing across claims, because that is a rule or a form problem rather than a partner problem"
],
"not": [
"Does not decide whether an activity was worth funding or hold the fund balance, which is the fund-allocator agent, and does not commit, release or pay money.",
"Does not judge whether the activity worked, which is the analytics and partner-monitor agents reading what it produced; this agent only establishes that it happened as approved.",
"Does not ask the partner for what is missing or tell them what was paid, which is the partner-manager agent.",
"Does not write the eligible activity list it scores against."
],
"processes": [
{
"process": "ref/prt/approve-a-fund-request",
"activities": [
"Agree What Counts as Proof"
]
},
{
"process": "ref/prt/check-and-pay-a-claim",
"activities": [
"Check the Claim Is Complete",
"Match the Claim to Its Approval",
"Check the Evidence of the Activity",
"Check Each Cost Is Eligible",
"Check the Invoices",
"Check Nothing Is Claimed Twice",
"Score the Claim",
"Settle a Line the Checks Could Not",
"Record What Was Learned"
]
}
]
}
}
}
# claim-check 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/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/claim-check
--- name: check-a-claim-against-its-approval description: "Checks the claim one question at a time, each pass leaving its own finding: every document present, the activity the same one that was approved on date, place and scope, each cost eligible, the invoices real, and nothing claimed a second time somewhere else. Use it when running `ref/prt/check-and-pay-a-claim`." license: CC-BY-4.0 metadata: agent: claim-check agent-version: "1" --- # Check a claim against its approval ## What it does Checks the claim one question at a time, each pass leaving its own finding: every document present, the activity the same one that was approved on date, place and scope, each cost eligible, the invoices real, and nothing claimed a second time somewhere else. ## 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 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) - **Check Nothing Is Claimed Twice** - `ref/prt/check-and-pay-a-claim`, activity 8 - [Check and Pay a Claim](../../../../processes/partners/check-and-pay-a-claim.md) - **Check the Claim Is Complete** - `ref/prt/check-and-pay-a-claim`, activity 2 - [Check and Pay a Claim](../../../../processes/partners/check-and-pay-a-claim.md) - **Check the Evidence of the Activity** - `ref/prt/check-and-pay-a-claim`, activity 4 - [Check and Pay a Claim](../../../../processes/partners/check-and-pay-a-claim.md) - **Check the Invoices** - `ref/prt/check-and-pay-a-claim`, activity 6 - [Check and Pay a Claim](../../../../processes/partners/check-and-pay-a-claim.md) - **Match the Claim to Its Approval** - `ref/prt/check-and-pay-a-claim`, activity 3 - [Check and Pay a Claim](../../../../processes/partners/check-and-pay-a-claim.md) ## What to record Per claim: the approval it was checked against, at its version, and the evidence list agreed at that approval. The completeness check, naming every document the approval asked for and whether it arrived. The match between the activity claimed and the activity approved, on date, place and scope. Each evidence item marked present, missing or insufficient. Each cost line scored against the eligible activity list at its version, with the rule it passes or fails. The invoice check, naming amounts, dates, tax treatment and who was actually paid. The duplicate check, naming where else a cost appeared if it did. The score, with the amount payable, the amount cut, and a reason on every cut. For any line the rules could not reach, the person who decided it and what they decided. A run can be replayed line by line from what it left behind. 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: fix-the-evidence-before-the-money-is-spent description: Settles at approval time what the claim will have to carry, so the evidence list is agreed with the partner before anything is spent and is not added to afterwards. Use it when running `ref/prt/approve-a-fund-request`. license: CC-BY-4.0 metadata: agent: claim-check agent-version: "1" --- # Fix the evidence before the money is spent ## What it does Settles at approval time what the claim will have to carry, so the evidence list is agreed with the partner before anything is spent and is not added to afterwards. ## Where it happens The agent does this in one activity across one reference process. Each one names the activity as that process words it. - **Agree What Counts as Proof** - `ref/prt/approve-a-fund-request`, activity 8 - [Approve a Fund Request](../../../../processes/partners/approve-a-fund-request.md) ## What to record Per claim: the approval it was checked against, at its version, and the evidence list agreed at that approval. The completeness check, naming every document the approval asked for and whether it arrived. The match between the activity claimed and the activity approved, on date, place and scope. Each evidence item marked present, missing or insufficient. Each cost line scored against the eligible activity list at its version, with the rule it passes or fails. The invoice check, naming amounts, dates, tax treatment and who was actually paid. The duplicate check, naming where else a cost appeared if it did. The score, with the amount payable, the amount cut, and a reason on every cut. For any line the rules could not reach, the person who decided it and what they decided. A run can be replayed line by line from what it left behind. 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: record-what-the-checks-keep-catching description: Files what the checks caught across a run, because a thing caught over and over is a rule or a form problem rather than a partner problem. Use it when running `ref/prt/check-and-pay-a-claim`. license: CC-BY-4.0 metadata: agent: claim-check agent-version: "1" --- # Record what the checks keep catching ## What it does Files what the checks caught across a run, because a thing caught over and over is a rule or a form problem rather than a partner problem. ## Where it happens The agent does this in one activity across one reference process. Each one names the activity as that process words it. - **Record What Was Learned** - `ref/prt/check-and-pay-a-claim`, activity 17 - [Check and Pay a Claim](../../../../processes/partners/check-and-pay-a-claim.md) ## What to record Per claim: the approval it was checked against, at its version, and the evidence list agreed at that approval. The completeness check, naming every document the approval asked for and whether it arrived. The match between the activity claimed and the activity approved, on date, place and scope. Each evidence item marked present, missing or insufficient. Each cost line scored against the eligible activity list at its version, with the rule it passes or fails. The invoice check, naming amounts, dates, tax treatment and who was actually paid. The duplicate check, naming where else a cost appeared if it did. The score, with the amount payable, the amount cut, and a reason on every cut. For any line the rules could not reach, the person who decided it and what they decided. A run can be replayed line by line from what it left behind. 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: score-the-claim description: Scores the claim into pays in full, pays in part or does not pay, with the amount payable, the amount cut, and the rule it fails or the evidence it lacks named on every cut. Use it when running `ref/prt/check-and-pay-a-claim`. license: CC-BY-4.0 metadata: agent: claim-check agent-version: "1" --- # Score the claim ## What it does Scores the claim into pays in full, pays in part or does not pay, with the amount payable, the amount cut, and the rule it fails or the evidence it lacks named on every cut. ## Where it happens The agent does this in one activity across one reference process. Each one names the activity as that process words it. - **Score the Claim** - `ref/prt/check-and-pay-a-claim`, activity 10 - [Check and Pay a Claim](../../../../processes/partners/check-and-pay-a-claim.md) ## What to record Per claim: the approval it was checked against, at its version, and the evidence list agreed at that approval. The completeness check, naming every document the approval asked for and whether it arrived. The match between the activity claimed and the activity approved, on date, place and scope. Each evidence item marked present, missing or insufficient. Each cost line scored against the eligible activity list at its version, with the rule it passes or fails. The invoice check, naming amounts, dates, tax treatment and who was actually paid. The duplicate check, naming where else a cost appeared if it did. The score, with the amount payable, the amount cut, and a reason on every cut. For any line the rules could not reach, the person who decided it and what they decided. A run can be replayed line by line from what it left behind. 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: settle-a-line-the-rules-cannot-reach description: Holds a line the checks could not settle, puts it to a person with the evidence and the rules it sits between, and records who decided it and what they decided. Use it when running `ref/prt/check-and-pay-a-claim`. license: CC-BY-4.0 metadata: agent: claim-check agent-version: "1" --- # Settle a line the rules cannot reach ## What it does Holds a line the checks could not settle, puts it to a person with the evidence and the rules it sits between, and records who decided it and what they decided. ## Where it happens The agent does this in one activity across one reference process. Each one names the activity as that process words it. - **Settle a Line the Checks Could Not** - `ref/prt/check-and-pay-a-claim`, activity 11 - [Check and Pay a Claim](../../../../processes/partners/check-and-pay-a-claim.md) ## What to record Per claim: the approval it was checked against, at its version, and the evidence list agreed at that approval. The completeness check, naming every document the approval asked for and whether it arrived. The match between the activity claimed and the activity approved, on date, place and scope. Each evidence item marked present, missing or insufficient. Each cost line scored against the eligible activity list at its version, with the rule it passes or fails. The invoice check, naming amounts, dates, tax treatment and who was actually paid. The duplicate check, naming where else a cost appeared if it did. The score, with the amount payable, the amount cut, and a reason on every cut. For any line the rules could not reach, the person who decided it and what they decided. A run can be replayed line by line from what it left behind. 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 7 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"
},
"partner-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/partner-record"
},
"agreement-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/agreement-record"
},
"crm": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/crm"
},
"analytics": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/analytics"
},
"partner-portal": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/partner-portal"
},
"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.
2 processes, 10 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.
Agree What Counts as Proof
Check the Claim Is Complete · Match the Claim to Its Approval · Check the Evidence of the Activity · Check Each Cost Is Eligible · Check the Invoices · Check Nothing Is Claimed Twice · Score the Claim · Settle a Line the Checks Could Not · Record What Was Learned
What it writes down
Per claim: the approval it was checked against, at its version, and the evidence list agreed at that approval. The completeness check, naming every document the approval asked for and whether it arrived. The match between the activity claimed and the activity approved, on date, place and scope. Each evidence item marked present, missing or insufficient. Each cost line scored against the eligible activity list at its version, with the rule it passes or fails. The invoice check, naming amounts, dates, tax treatment and who was actually paid. The duplicate check, naming where else a cost appeared if it did. The score, with the amount payable, the amount cut, and a reason on every cut. For any line the rules could not reach, the person who decided it and what they decided. A run can be replayed line by line from what it left behind.
What it will not do
Does not decide whether an activity was worth funding or hold the fund balance, which is the fund-allocator agent, and does not commit, release or pay money. Does not judge whether the activity worked, which is the analytics and partner-monitor agents reading what it produced; this agent only establishes that it happened as approved. Does not ask the partner for what is missing or tell them what was paid, which is the partner-manager agent. Does not write the eligible activity list it scores against.
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: claim-check 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.
- Check Before You Pay MCP server · leosuhail-cmd.github.io · hosted · mirrored from the MCP registry Before an agent pays, get a verdict and a keepable receipt. Not insurance. Not custody.
- consistency-gate MCP server · humanified.dk · hosted · mirrored from the MCP registry Check claims against a fact-store: consistent, contradicts, or unverifiable — with a receipt.
- compliance-evidence MCP server · dropwatchhq.com · hosted · mirrored from the MCP registry Dated, signed compliance-evidence packs: gov-fact-grounded claims + exclusion screens + trap-facts.