Signature manager
signature-manager v1Takes an agreement from an agreed text to an executed one. Confirms who signs on each side, in what order, on which document and under what authority, sends the right version to the right people, and files the executed copy with every exhibit it names. Afterwards it is the agent that can say what was actually signed: which version, by whom, on what date, and which promises the paper carries. It withdraws a document that should no longer be out to sign, and it never signs anything itself.
The abstract agent
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.
Runs collect-and-report to establish who signs on each side and what each signer has to see first, and assessment on the executed document: who signed, under what authority, and whether every page and exhibit it refers to is present. Runs a second assessment on the promises the sale made, marking each one carried by the agreement, carried by a side letter, or said and not binding. Convenes the briefing where the seller, the account team, finance and delivery hear one booking, and the debrief on what had to be corrected between signature and booking. Runs roll-call over an agreement waiting to be booked. Takes the agreed text from the redline-reviewer agent, hands the executed agreement to the order-check agent, and hands the marked promise list to the handover-coordinator agent.
The plugin
What is in the package
6 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.
signature-manager · 11 files · 1.0.0
com.agentcatalog.agent/NOT.mdWhat the agent does not do, and when it asks a person.
# Where this abstract agent stops Does not negotiate the words. What a clause says is settled by the redline-reviewer agent with legal, and this agent takes the text that came out of that. Does not price anything and does not book the order, which is the order-check agent's work against the terms this agent lifted out of the paper. Does not sign and does not countersign for the organization: signature is a human gate, and an agent that could execute an agreement would make the record it keeps worthless. ## What always goes to a person - a signer without the authority to sign, to the legal reviewer and the seller, with the signature recorded as unconfirmed and nothing booked against the document in hand - an entity named on the paper that the entity list does not hold, to whoever owns that list, before anything is recorded against it - every term off the standard paper, to the legal reviewer and the finance approver by name, before the booking rather than after it - a promise the agreement does not carry, to the person who decides whether the organization honors it anyway, before the customer hears from anybody - a signer who has changed or become unavailable while a document is out to sign, to the deal owner, with the path confirmed again before it goes out a second time
com.agentcatalog.agent/RECORDS.mdThe records the agent must leave behind.
# The records this abstract agent must leave
This is the contract. An agent implementing `signature-manager` leaves
the following behind, on every run.
Per agreement: the executed document at a version, with each exhibit it
names marked present or missing. The signers on both sides, the
authority each signed under, and the signature date the term runs from.
The buying entity and the selling entity as matched to the entity list,
with the tax and address record for each. Every term off the standard
paper, named as non-standard, with the person who accepted it and the
date. Each promise made during the sale marked binding, carried by a
side letter, or not binding, with the clause behind every binding one.
The signature path as confirmed, and the date and version each document
went out on. What had to be corrected between signature and booking, and
which of it belongs in the next version of the paper. Somebody auditing
a run can say which version was signed, by whom, and what it obliges.
An agent that leaves less than this does not implement
`signature-manager`, whatever else it does well.
com.agentcatalog.agent/SERVERS.mdThe systems the agent needs, by role rather than by product.
# The systems this abstract agent needs
Five 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 contract repository | read | The executed document at a version, with every exhibit and amendment it names. |
| the signature system | write | The document goes to the named signers in order, and comes back out of there when a deal is lost. |
| the entity list | read | The entity that buys and the one that sells, matched to what the organization holds rather than to the address block on the paper. |
| the approval record | read | Which term off the standard paper is signed for, by whom, against which version. |
| the notification channel | write | The people who act on a booking hear the same booking at the same time. |
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.
plugin.jsonThe manifest. It lists the skills and the systems the agent needs.
{
"$schema": "https://agent-plugins.org/schemas/1.1.0/plugin.schema.json",
"name": "signature-manager",
"version": "1.0.0",
"description": "The signature-manager abstract agent. Takes an agreement from an agreed text to an executed one. Confirms who signs on each side, in what order, on which document and under what authority, sends the right version to the right people, and files the executed copy with every exhibit it names.",
"author": {
"name": "AgentCatalog",
"url": "https://agentcatalog.com"
},
"homepage": "https://agentcatalog.com/abstract-agents/signature-manager",
"repository": "https://github.com/jeffrschneider/agentcatalog",
"license": "CC-BY-4.0",
"keywords": [
"abstract-agent",
"reference",
"sales",
"book-the-order",
"run-the-close-plan",
"hand-over-to-delivery",
"abstract"
],
"extensions": {
"com.agentcatalog.agent": {
"agent": "signature-manager",
"agentVersion": 1,
"department": "sales",
"abstract": true,
"works": "Runs collect-and-report to establish who signs on each side and what each signer has to see first, and assessment on the executed document: who signed, under what authority, and whether every page and exhibit it refers to is present. Runs a second assessment on the promises the sale made, marking each one carried by the agreement, carried by a side letter, or said and not binding. Convenes the briefing where the seller, the account team, finance and delivery hear one booking, and the debrief on what had to be corrected between signature and booking. Runs roll-call over an agreement waiting to be booked. Takes the agreed text from the redline-reviewer agent, hands the executed agreement to the order-check agent, and hands the marked promise list to the handover-coordinator agent.",
"servers": [
{
"name": "the contract repository",
"role": "contract-repository",
"access": "read",
"needs": "The executed document at a version, with every exhibit and amendment it names."
},
{
"name": "the signature system",
"role": "signature-system",
"access": "write",
"needs": "The document goes to the named signers in order, and comes back out of there when a deal is lost."
},
{
"name": "the entity list",
"role": "entity-list",
"access": "read",
"needs": "The entity that buys and the one that sells, matched to what the organization holds rather than to the address block on the paper."
},
{
"name": "the approval record",
"role": "approval-record",
"access": "read",
"needs": "Which term off the standard paper is signed for, by whom, against which version."
},
{
"name": "the notification channel",
"role": "notification-channel",
"access": "write",
"needs": "The people who act on a booking hear the same booking at the same time."
}
],
"records": [
"Per agreement: the executed document at a version, with each exhibit it names marked present or missing.",
"The signers on both sides, the authority each signed under, and the signature date the term runs from.",
"The buying entity and the selling entity as matched to the entity list, with the tax and address record for each.",
"Every term off the standard paper, named as non-standard, with the person who accepted it and the date.",
"Each promise made during the sale marked binding, carried by a side letter, or not binding, with the clause behind every binding one.",
"The signature path as confirmed, and the date and version each document went out on.",
"What had to be corrected between signature and booking, and which of it belongs in the next version of the paper.",
"Somebody auditing a run can say which version was signed, by whom, and what it obliges."
],
"escalates": [
"a signer without the authority to sign, to the legal reviewer and the seller, with the signature recorded as unconfirmed and nothing booked against the document in hand",
"an entity named on the paper that the entity list does not hold, to whoever owns that list, before anything is recorded against it",
"every term off the standard paper, to the legal reviewer and the finance approver by name, before the booking rather than after it",
"a promise the agreement does not carry, to the person who decides whether the organization honors it anyway, before the customer hears from anybody",
"a signer who has changed or become unavailable while a document is out to sign, to the deal owner, with the path confirmed again before it goes out a second time"
],
"not": [
"Does not negotiate the words.",
"What a clause says is settled by the redline-reviewer agent with legal, and this agent takes the text that came out of that.",
"Does not price anything and does not book the order, which is the order-check agent's work against the terms this agent lifted out of the paper.",
"Does not sign and does not countersign for the organization: signature is a human gate, and an agent that could execute an agreement would make the record it keeps worthless."
],
"processes": [
{
"process": "ref/sls/book-the-order",
"activities": [
"Take in the Executed Agreement",
"Confirm the Signature and the Signer",
"Identify the Buying Entity",
"Settle the Non-Standard Terms",
"Tell the People Who Need to Know",
"Record What Had to Be Fixed"
]
},
{
"process": "ref/sls/hand-over-to-delivery",
"activities": [
"Separate the Contract from the Conversation"
]
},
{
"process": "ref/sls/record-a-lost-deal",
"activities": [
"Stop the Open Work"
]
},
{
"process": "ref/sls/review-the-redlines",
"activities": [
"Hand the Text to Signature"
]
},
{
"process": "ref/sls/run-the-close-plan",
"activities": [
"Confirm the Signature Path",
"Execute the Signature"
]
}
]
}
}
}
README.mdWhat the package is, and why it carries no mcp.json.
# signature-manager 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 six 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/sls/book-the-order`, `ref/sls/hand-over-to-delivery`, `ref/sls/record-a-lost-deal`, `ref/sls/review-the-redlines`, `ref/sls/run-the-close-plan`. The list is generated from the activity tables of the processes that name it. https://agentcatalog.com/abstract-agents/signature-manager
skills/check-the-executed-document/SKILL.mdTakes the executed copy in with every exhibit it names, and confirms who signed on each side, under what authority, and on what date. Use it when running `ref/sls/book-the-order`.
--- name: check-the-executed-document description: Takes the executed copy in with every exhibit it names, and confirms who signed on each side, under what authority, and on what date. Use it when running `ref/sls/book-the-order`. license: CC-BY-4.0 metadata: agent: signature-manager agent-version: "1" --- # Check the executed document ## What it does Takes the executed copy in with every exhibit it names, and confirms who signed on each side, under what authority, and on what date. An exhibit that is not there is named as missing rather than assumed. ## Where it happens The agent does this in two activities across one reference process. Each one names the activity as that process words it. - **Confirm the Signature and the Signer** - `ref/sls/book-the-order`, activity 2 - [Book the Order](../../../../processes/sales/book-the-order.md) - **Take in the Executed Agreement** - `ref/sls/book-the-order`, activity 1 - [Book the Order](../../../../processes/sales/book-the-order.md) ## What to record Per agreement: the executed document at a version, with each exhibit it names marked present or missing. The signers on both sides, the authority each signed under, and the signature date the term runs from. The buying entity and the selling entity as matched to the entity list, with the tax and address record for each. Every term off the standard paper, named as non-standard, with the person who accepted it and the date. Each promise made during the sale marked binding, carried by a side letter, or not binding, with the clause behind every binding one. The signature path as confirmed, and the date and version each document went out on. What had to be corrected between signature and booking, and which of it belongs in the next version of the paper. Somebody auditing a run can say which version was signed, by whom, and what it obliges. 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`.
skills/close-the-signature-out/SKILL.mdPuts one booking in front of everybody who acts on it at the same time, so nobody works from an older version of what was signed. Use it when running `ref/sls/book-the-order`.
--- name: close-the-signature-out description: Puts one booking in front of everybody who acts on it at the same time, so nobody works from an older version of what was signed. Use it when running `ref/sls/book-the-order`. license: CC-BY-4.0 metadata: agent: signature-manager agent-version: "1" --- # Close the signature out ## What it does Puts one booking in front of everybody who acts on it at the same time, so nobody works from an older version of what was signed. Writes down what had to be corrected between signature and booking, and which of it belongs in the next version of the paper. ## Where it happens The agent does this in two activities across one reference process. Each one names the activity as that process words it. - **Record What Had to Be Fixed** - `ref/sls/book-the-order`, activity 16 - [Book the Order](../../../../processes/sales/book-the-order.md) - **Tell the People Who Need to Know** - `ref/sls/book-the-order`, activity 15 - [Book the Order](../../../../processes/sales/book-the-order.md) ## What to record Per agreement: the executed document at a version, with each exhibit it names marked present or missing. The signers on both sides, the authority each signed under, and the signature date the term runs from. The buying entity and the selling entity as matched to the entity list, with the tax and address record for each. Every term off the standard paper, named as non-standard, with the person who accepted it and the date. Each promise made during the sale marked binding, carried by a side letter, or not binding, with the clause behind every binding one. The signature path as confirmed, and the date and version each document went out on. What had to be corrected between signature and booking, and which of it belongs in the next version of the paper. Somebody auditing a run can say which version was signed, by whom, and what it obliges. 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`.
skills/control-what-is-out-to-sign/SKILL.mdSends the right version to the named signers in the agreed order, and takes a document back out of signature when it should no longer be out there, such as when the deal is lost. Use it when running `ref/sls/record-a-lost-deal` and `ref/sls/run-the-close-plan`.
--- name: control-what-is-out-to-sign description: Sends the right version to the named signers in the agreed order, and takes a document back out of signature when it should no longer be out there, such as when the deal is lost. Use it when running `ref/sls/record-a-lost-deal` and `ref/sls/run-the-close-plan`. license: CC-BY-4.0 metadata: agent: signature-manager agent-version: "1" --- # Control what is out to sign ## What it does Sends the right version to the named signers in the agreed order, and takes a document back out of signature when it should no longer be out there, such as when the deal is lost. The signing itself stays a human step. ## Where it happens The agent does this in two activities across two reference processes. Each one names the activity as that process words it. - **Execute the Signature** - `ref/sls/run-the-close-plan`, activity 15 - [Run the Close Plan](../../../../processes/sales/run-the-close-plan.md) - **Stop the Open Work** - `ref/sls/record-a-lost-deal`, activity 9 - [Record a Lost Deal](../../../../processes/sales/record-a-lost-deal.md) ## What to record Per agreement: the executed document at a version, with each exhibit it names marked present or missing. The signers on both sides, the authority each signed under, and the signature date the term runs from. The buying entity and the selling entity as matched to the entity list, with the tax and address record for each. Every term off the standard paper, named as non-standard, with the person who accepted it and the date. Each promise made during the sale marked binding, carried by a side letter, or not binding, with the clause behind every binding one. The signature path as confirmed, and the date and version each document went out on. What had to be corrected between signature and booking, and which of it belongs in the next version of the paper. Somebody auditing a run can say which version was signed, by whom, and what it obliges. 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`.
skills/mark-which-promises-the-paper-carries/SKILL.mdReads the promises made during the sale against the executed text and marks each one carried by the agreement, carried by a side letter, or said and not binding. Use it when running `ref/sls/hand-over-to-delivery`.
--- name: mark-which-promises-the-paper-carries description: Reads the promises made during the sale against the executed text and marks each one carried by the agreement, carried by a side letter, or said and not binding. Use it when running `ref/sls/hand-over-to-delivery`. license: CC-BY-4.0 metadata: agent: signature-manager agent-version: "1" --- # Mark which promises the paper carries ## What it does Reads the promises made during the sale against the executed text and marks each one carried by the agreement, carried by a side letter, or said and not binding. Every binding one names the clause behind it. ## Where it happens The agent does this in one activity across one reference process. Each one names the activity as that process words it. - **Separate the Contract from the Conversation** - `ref/sls/hand-over-to-delivery`, activity 6 - [Hand over to Delivery](../../../../processes/sales/hand-over-to-delivery.md) ## What to record Per agreement: the executed document at a version, with each exhibit it names marked present or missing. The signers on both sides, the authority each signed under, and the signature date the term runs from. The buying entity and the selling entity as matched to the entity list, with the tax and address record for each. Every term off the standard paper, named as non-standard, with the person who accepted it and the date. Each promise made during the sale marked binding, carried by a side letter, or not binding, with the clause behind every binding one. The signature path as confirmed, and the date and version each document went out on. What had to be corrected between signature and booking, and which of it belongs in the next version of the paper. Somebody auditing a run can say which version was signed, by whom, and what it obliges. 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`.
skills/name-the-parties-and-the-terms-off-the-standard-paper/SKILL.mdMatches the buying entity and the selling entity to the entity list the organization holds rather than to the address block on the paper. Use it when running `ref/sls/book-the-order`.
--- name: name-the-parties-and-the-terms-off-the-standard-paper description: Matches the buying entity and the selling entity to the entity list the organization holds rather than to the address block on the paper. Use it when running `ref/sls/book-the-order`. license: CC-BY-4.0 metadata: agent: signature-manager agent-version: "1" --- # Name the parties and the terms off the standard paper ## What it does Matches the buying entity and the selling entity to the entity list the organization holds rather than to the address block on the paper. Names every term that differs from the standard paper, with the person who accepted it and the date. ## Where it happens The agent does this in two activities across one reference process. Each one names the activity as that process words it. - **Identify the Buying Entity** - `ref/sls/book-the-order`, activity 3 - [Book the Order](../../../../processes/sales/book-the-order.md) - **Settle the Non-Standard Terms** - `ref/sls/book-the-order`, activity 9 - [Book the Order](../../../../processes/sales/book-the-order.md) ## What to record Per agreement: the executed document at a version, with each exhibit it names marked present or missing. The signers on both sides, the authority each signed under, and the signature date the term runs from. The buying entity and the selling entity as matched to the entity list, with the tax and address record for each. Every term off the standard paper, named as non-standard, with the person who accepted it and the date. Each promise made during the sale marked binding, carried by a side letter, or not binding, with the clause behind every binding one. The signature path as confirmed, and the date and version each document went out on. What had to be corrected between signature and booking, and which of it belongs in the next version of the paper. Somebody auditing a run can say which version was signed, by whom, and what it obliges. 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`.
skills/set-the-signature-path/SKILL.mdTakes the agreed text from the people who settled the words and confirms who signs on each side, in what order, on which document and under what authority. Use it when running `ref/sls/review-the-redlines` and `ref/sls/run-the-close-plan`.
--- name: set-the-signature-path description: Takes the agreed text from the people who settled the words and confirms who signs on each side, in what order, on which document and under what authority. Use it when running `ref/sls/review-the-redlines` and `ref/sls/run-the-close-plan`. license: CC-BY-4.0 metadata: agent: signature-manager agent-version: "1" --- # Set the signature path ## What it does Takes the agreed text from the people who settled the words and confirms who signs on each side, in what order, on which document and under what authority. Nothing goes out to sign until the path is settled. ## Where it happens The agent does this in two activities across two reference processes. Each one names the activity as that process words it. - **Confirm the Signature Path** - `ref/sls/run-the-close-plan`, activity 9 - [Run the Close Plan](../../../../processes/sales/run-the-close-plan.md) - **Hand the Text to Signature** - `ref/sls/review-the-redlines`, activity 16 - [Review the Redlines](../../../../processes/sales/review-the-redlines.md) ## What to record Per agreement: the executed document at a version, with each exhibit it names marked present or missing. The signers on both sides, the authority each signed under, and the signature date the term runs from. The buying entity and the selling entity as matched to the entity list, with the tax and address record for each. Every term off the standard paper, named as non-standard, with the person who accepted it and the date. Each promise made during the sale marked binding, carried by a side letter, or not binding, with the clause behind every binding one. The signature path as confirmed, and the date and version each document went out on. What had to be corrected between signature and booking, and which of it belongs in the next version of the paper. Somebody auditing a run can say which version was signed, by whom, and what it obliges. 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`.
mcp.jsonNot in the package.
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.
Setting 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 5 roles, and the access level beside each one is the most the work needs.
contract-repository · readsignature-system · writeentity-list · readapproval-record · readnotification-channel · write
mcp.json
You write this file. It is not part of the package.
{
"$schema": "https://agent-plugins.org/schemas/1.1.0/mcp.schema.json",
"mcpServers": {
"contract-repository": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/contract-repository"
},
"signature-system": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/signature-system"
},
"entity-list": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/entity-list"
},
"approval-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/approval-record"
},
"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.
Where it works
5 processes, 11 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.
Book the Orderref/sls/book-the-order · 16 activities
Take in the Executed Agreement · Confirm the Signature and the Signer · Identify the Buying Entity · Settle the Non-Standard Terms · Tell the People Who Need to Know · Record What Had to Be Fixed
Hand over to Deliveryref/sls/hand-over-to-delivery · 16 activities
Separate the Contract from the Conversation
Record a Lost Dealref/sls/record-a-lost-deal · 14 activities
Stop the Open Work
Review the Redlinesref/sls/review-the-redlines · 16 activities
Hand the Text to Signature
Run the Close Planref/sls/run-the-close-plan · 16 activities
Confirm the Signature Path · Execute the Signature
The records it leaves
What it writes down
Per agreement: the executed document at a version, with each exhibit it names marked present or missing. The signers on both sides, the authority each signed under, and the signature date the term runs from. The buying entity and the selling entity as matched to the entity list, with the tax and address record for each. Every term off the standard paper, named as non-standard, with the person who accepted it and the date. Each promise made during the sale marked binding, carried by a side letter, or not binding, with the clause behind every binding one. The signature path as confirmed, and the date and version each document went out on. What had to be corrected between signature and booking, and which of it belongs in the next version of the paper. Somebody auditing a run can say which version was signed, by whom, and what it obliges.
Where it stops
What it will not do
Does not negotiate the words. What a clause says is settled by the redline-reviewer agent with legal, and this agent takes the text that came out of that. Does not price anything and does not book the order, which is the order-check agent's work against the terms this agent lifted out of the paper. Does not sign and does not countersign for the organization: signature is a human gate, and an agent that could execute an agreement would make the record it keeps worthless.
These limits are written into the job on purpose, so that everyone adopting the process knows which decisions stay with a person.
Agents built from this plugin
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.
declare it
implements: signature-manager v1
One line in your agent's manifest. The catalog checks it against the records your runs actually leave.
A guess, not a claim
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.
Might do the job
Things that could be the worker: an agent, a packaged product, a plugin.
- The Website Specification — A2A agent Agent · specification.website Read-only A2A agent that answers natural-language questions about The Website Specification and returns matching topics with status, canonical URL,…
Might be reached for
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.
- agent-transaction-control MCP server · flint.network · hosted · mirrored from the MCP registry Issue Agent Passports and verify agent authority before value moves. Signed verification records.
- mcp MCP server · swiftsign.ca · hosted · mirrored from the MCP registry E-signatures for agents: mint a sandbox key, send PDFs, track status, download the sealed result.
- Tersign Evidence MCP server · tersignhq.github.io · run it yourself · mirrored from the MCP registry Counter-signed evidence records for agent commerce: receipts, verification, dispute envelopes.