Tool administrator
tool-administrator v1Runs a tool once it is in. It holds who may get in and at what role, closes a leaver's account against the leaving record, keeps the configuration at a version so a change can be seen, dated and taken back, and sets the licences paid for against the licences used. A change is tried away from live before it is applied, and a request that is not what the tool is for is refused in writing with the process it belongs to named. It carries the standing question of whether the tool still earns its place into the review, and when the answer is retirement it tells the people who use it, takes the export while the tool still runs, and closes the accounts on the notice the agreement requires.
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 allocate-and-reconcile on the licence count, setting licences paid for against licences used and naming every licence unused past the limit. Runs roll-call on access for the life of the tool, and sits in the access review a person holds. Takes the standing review's assessment from the stack-planner agent and records the decision that comes out of the decide-and-announce. Takes a live link from the integration-keeper agent with the flow record, the credentials and the date it is next checked, and gives that agent the link check back on its cadence. Reads supplier changes from the supplier-check agent and turns the ones that force work into change requests. Sits in the approval that has to clear before a tool is switched off.
What is in the package
7 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 the tool stays. It brings the use, the cost, the findings and the supplier changes to the review, the stack-planner agent runs the review, and a named person decides. Does not set the roles and permissions on its own or clear the access review, which are human gates. Does not build or change the links either side, which is the integration-keeper agent. Does not choose a tool, negotiate a term or end an agreement on its own. Does not bend the tool to carry work it was not chosen for. ## What always goes to a person - a leaver who kept an account, to the security reviewer as a finding against the joiner and leaver path, with how long it stood open - more licences used than are held, to whoever owns the budget, who says in writing whether licences are bought or accounts are closed - a change that cannot be taken back, which is not applied outside a stated window with the tool's owner watching - an account nobody can account for, to the security reviewer, with the role it holds - somebody still writing to the tool after the read-only date, and the records written after it are exported again
# The records this abstract agent must leave
This is the contract. An agent implementing `tool-administrator` leaves
the following behind, on every run.
The entry as it was taken on: the owner, the licence, the term and the
process the tool runs. Every account open today with its role and its
named approver, and every closure with its date and how long the account
stood after the leaving record. The configuration at a version, each
change carrying its date, the request behind it, what the trial away
from live showed, and the way back that was kept. Each licence count
setting licences paid for against licences used, naming every licence
unused past the limit. Every refused request, with the reason and the
process it belongs to. The review recorded with its decision, its date,
the evidence it was made on and the date the next one falls. In a
retirement: who was told and when, the export with everything the tool
held that it could not take, every link stopped with what it was
carrying, the read-only date, the closed accounts, the notice given and
the final invoice.
An agent that leaves less than this does not implement
`tool-administrator`, 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 tool | write | Accounts, roles and configuration are this agent's standing work. |
| the account record | write | Every account with the role it holds and the person who approved it. |
| the configuration record | write | Each change with its date, its version, the request behind it and the way back. |
| the identity system | read | Joiners and leavers, so an account is opened against a job and closed against a leaving record. |
| a non-live environment | write | No change is made straight to live where a copy exists. |
| the flow record | read | What the links either side carry, and when each was last checked. |
| the stack record | read | The entry, the licence, the term and the process the tool runs. |
| the budget record | read | What the sellers cost, read against what is actually used. |
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": "tool-administrator",
"version": "1.0.0",
"description": "The tool-administrator abstract agent. Runs a tool once it is in. It holds who may get in and at what role, closes a leaver's account against the leaving record, keeps the configuration at a version so a change can be seen, dated and taken back, and sets the licences paid for against the licences used.",
"author": {
"name": "AgentCatalog",
"url": "https://agentcatalog.com"
},
"homepage": "https://agentcatalog.com/abstract-agents/tool-administrator",
"repository": "https://github.com/jeffrschneider/agentcatalog",
"license": "CC-BY-4.0",
"keywords": [
"abstract-agent",
"reference",
"revenue-operations",
"administer-a-tool",
"retire-a-tool",
"integrate-a-tool",
"abstract"
],
"extensions": {
"com.agentcatalog.agent": {
"agent": "tool-administrator",
"agentVersion": 1,
"department": "revenue-operations",
"abstract": true,
"works": "Runs allocate-and-reconcile on the licence count, setting licences paid for against licences used and naming every licence unused past the limit. Runs roll-call on access for the life of the tool, and sits in the access review a person holds. Takes the standing review's assessment from the stack-planner agent and records the decision that comes out of the decide-and-announce. Takes a live link from the integration-keeper agent with the flow record, the credentials and the date it is next checked, and gives that agent the link check back on its cadence. Reads supplier changes from the supplier-check agent and turns the ones that force work into change requests. Sits in the approval that has to clear before a tool is switched off.",
"servers": [
{
"name": "the tool",
"role": "tool",
"access": "write",
"needs": "Accounts, roles and configuration are this agent's standing work."
},
{
"name": "the account record",
"role": "account-record",
"access": "write",
"needs": "Every account with the role it holds and the person who approved it."
},
{
"name": "the configuration record",
"role": "configuration-record",
"access": "write",
"needs": "Each change with its date, its version, the request behind it and the way back."
},
{
"name": "the identity system",
"role": "identity-system",
"access": "read",
"needs": "Joiners and leavers, so an account is opened against a job and closed against a leaving record."
},
{
"name": "a non-live environment",
"role": "non-live-environment",
"access": "write",
"needs": "No change is made straight to live where a copy exists."
},
{
"name": "the flow record",
"role": "flow-record",
"access": "read",
"needs": "What the links either side carry, and when each was last checked."
},
{
"name": "the stack record",
"role": "stack-record",
"access": "read",
"needs": "The entry, the licence, the term and the process the tool runs."
},
{
"name": "the budget record",
"role": "budget-record",
"access": "read",
"needs": "What the sellers cost, read against what is actually used."
}
],
"records": [
"The entry as it was taken on: the owner, the licence, the term and the process the tool runs.",
"Every account open today with its role and its named approver, and every closure with its date and how long the account stood after the leaving record.",
"The configuration at a version, each change carrying its date, the request behind it, what the trial away from live showed, and the way back that was kept.",
"Each licence count setting licences paid for against licences used, naming every licence unused past the limit.",
"Every refused request, with the reason and the process it belongs to.",
"The review recorded with its decision, its date, the evidence it was made on and the date the next one falls.",
"In a retirement: who was told and when, the export with everything the tool held that it could not take, every link stopped with what it was carrying, the read-only date, the closed accounts, the notice given and the final invoice."
],
"escalates": [
"a leaver who kept an account, to the security reviewer as a finding against the joiner and leaver path, with how long it stood open",
"more licences used than are held, to whoever owns the budget, who says in writing whether licences are bought or accounts are closed",
"a change that cannot be taken back, which is not applied outside a stated window with the tool's owner watching",
"an account nobody can account for, to the security reviewer, with the role it holds",
"somebody still writing to the tool after the read-only date, and the records written after it are exported again"
],
"not": [
"Does not decide whether the tool stays.",
"It brings the use, the cost, the findings and the supplier changes to the review, the stack-planner agent runs the review, and a named person decides.",
"Does not set the roles and permissions on its own or clear the access review, which are human gates.",
"Does not build or change the links either side, which is the integration-keeper agent.",
"Does not choose a tool, negotiate a term or end an agreement on its own.",
"Does not bend the tool to carry work it was not chosen for."
],
"processes": [
{
"process": "ref/rev/administer-a-tool",
"activities": [
"Take On the Tool",
"Set the Roles and the Permissions",
"Open and Close Accounts",
"Hold the Configuration at a Version",
"Take in Change Requests",
"Try the Change away from Live",
"Apply the Change",
"Keep the Licence Count Right",
"Take in Supplier Changes",
"Read Every Account Again",
"Run the Standing Review",
"Record the Review"
]
},
{
"process": "ref/rev/integrate-a-tool",
"activities": [
"Set the Access the Link Is Given",
"Switch It On",
"Hand It to the Administrator"
]
},
{
"process": "ref/rev/retire-a-tool",
"activities": [
"Tell the People Who Use It",
"Move the Process to Its New Home",
"Take the Export",
"Turn Off the Links",
"Stop New Work Going In",
"Close the Accounts and the Licence",
"Record What Was Learned"
]
}
]
}
}
}
# tool-administrator 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 seven 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/rev/administer-a-tool`, `ref/rev/integrate-a-tool`, `ref/rev/retire-a-tool`. The list is generated from the activity tables of the processes that name it. https://agentcatalog.com/abstract-agents/tool-administrator
--- name: bring-the-tool-to-its-standing-review description: Brings the use, the cost, the findings and the supplier changes to the review that asks whether the tool still earns its place, and records the decision with its date, its evidence and the date the next review falls. Use it when running `ref/rev/administer-a-tool`. license: CC-BY-4.0 metadata: agent: tool-administrator agent-version: "1" --- # Bring the tool to its standing review ## What it does Brings the use, the cost, the findings and the supplier changes to the review that asks whether the tool still earns its place, and records the decision with its date, its evidence and the date the next review falls. ## 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 the Review** - `ref/rev/administer-a-tool`, activity 15 - [Administer a Tool](../../../../processes/revenue-operations/administer-a-tool.md) - **Run the Standing Review** - `ref/rev/administer-a-tool`, activity 13 - [Administer a Tool](../../../../processes/revenue-operations/administer-a-tool.md) ## What to record The entry as it was taken on: the owner, the licence, the term and the process the tool runs. Every account open today with its role and its named approver, and every closure with its date and how long the account stood after the leaving record. The configuration at a version, each change carrying its date, the request behind it, what the trial away from live showed, and the way back that was kept. Each licence count setting licences paid for against licences used, naming every licence unused past the limit. Every refused request, with the reason and the process it belongs to. The review recorded with its decision, its date, the evidence it was made on and the date the next one falls. In a retirement: who was told and when, the export with everything the tool held that it could not take, every link stopped with what it was carrying, the read-only date, the closed accounts, the notice given and the final invoice. 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: give-a-link-its-own-access description: Gives a link its own credentials at the reach the agreed flows need and no wider, switches it on, and takes the running link over with the flow record and the date it is next checked. Use it when running `ref/rev/integrate-a-tool`. license: CC-BY-4.0 metadata: agent: tool-administrator agent-version: "1" --- # Give a link its own access ## What it does Gives a link its own credentials at the reach the agreed flows need and no wider, switches it on, and takes the running link over with the flow record and the date it is next checked. ## Where it happens The agent does this in three activities across one reference process. Each one names the activity as that process words it. - **Hand It to the Administrator** - `ref/rev/integrate-a-tool`, activity 15 - [Integrate a Tool](../../../../processes/revenue-operations/integrate-a-tool.md) - **Set the Access the Link Is Given** - `ref/rev/integrate-a-tool`, activity 6 - [Integrate a Tool](../../../../processes/revenue-operations/integrate-a-tool.md) - **Switch It On** - `ref/rev/integrate-a-tool`, activity 11 - [Integrate a Tool](../../../../processes/revenue-operations/integrate-a-tool.md) ## What to record The entry as it was taken on: the owner, the licence, the term and the process the tool runs. Every account open today with its role and its named approver, and every closure with its date and how long the account stood after the leaving record. The configuration at a version, each change carrying its date, the request behind it, what the trial away from live showed, and the way back that was kept. Each licence count setting licences paid for against licences used, naming every licence unused past the limit. Every refused request, with the reason and the process it belongs to. The review recorded with its decision, its date, the evidence it was made on and the date the next one falls. In a retirement: who was told and when, the export with everything the tool held that it could not take, every link stopped with what it was carrying, the read-only date, the closed accounts, the notice given and the final invoice. 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-who-may-get-in description: Sets the roles and what each one may do, opens an account against a job and closes it against a leaving record, and reads every account again on its cadence. Use it when running `ref/rev/administer-a-tool`. license: CC-BY-4.0 metadata: agent: tool-administrator agent-version: "1" --- # Hold who may get in ## What it does Sets the roles and what each one may do, opens an account against a job and closes it against a leaving record, and reads every account again on its cadence. A leaver who kept an account and an account nobody can account for both go to the security reviewer. ## Where it happens The agent does this in three activities across one reference process. Each one names the activity as that process words it. - **Open and Close Accounts** - `ref/rev/administer-a-tool`, activity 3 - [Administer a Tool](../../../../processes/revenue-operations/administer-a-tool.md) - **Read Every Account Again** - `ref/rev/administer-a-tool`, activity 12 - [Administer a Tool](../../../../processes/revenue-operations/administer-a-tool.md) - **Set the Roles and the Permissions** - `ref/rev/administer-a-tool`, activity 2 - [Administer a Tool](../../../../processes/revenue-operations/administer-a-tool.md) ## What to record The entry as it was taken on: the owner, the licence, the term and the process the tool runs. Every account open today with its role and its named approver, and every closure with its date and how long the account stood after the leaving record. The configuration at a version, each change carrying its date, the request behind it, what the trial away from live showed, and the way back that was kept. Each licence count setting licences paid for against licences used, naming every licence unused past the limit. Every refused request, with the reason and the process it belongs to. The review recorded with its decision, its date, the evidence it was made on and the date the next one falls. In a retirement: who was told and when, the export with everything the tool held that it could not take, every link stopped with what it was carrying, the read-only date, the closed accounts, the notice given and the final invoice. 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-sellers-paid-for-against-the-sellers-used description: Reads the sellers held against the sellers actually used, names every one unused past the limit, and takes more licences used than are held to whoever owns the budget, who says in writing whether licences are bought or accounts are closed. Use it when running `ref/rev/administer-a-tool`. license: CC-BY-4.0 metadata: agent: tool-administrator agent-version: "1" --- # Set the sellers paid for against the sellers used ## What it does Reads the sellers held against the sellers actually used, names every one unused past the limit, and takes more licences used than are held to whoever owns the budget, who says in writing whether licences are bought or accounts are closed. ## Where it happens The agent does this in one activity across one reference process. Each one names the activity as that process words it. - **Keep the Licence Count Right** - `ref/rev/administer-a-tool`, activity 8 - [Administer a Tool](../../../../processes/revenue-operations/administer-a-tool.md) ## What to record The entry as it was taken on: the owner, the licence, the term and the process the tool runs. Every account open today with its role and its named approver, and every closure with its date and how long the account stood after the leaving record. The configuration at a version, each change carrying its date, the request behind it, what the trial away from live showed, and the way back that was kept. Each licence count setting licences paid for against licences used, naming every licence unused past the limit. Every refused request, with the reason and the process it belongs to. The review recorded with its decision, its date, the evidence it was made on and the date the next one falls. In a retirement: who was told and when, the export with everything the tool held that it could not take, every link stopped with what it was carrying, the read-only date, the closed accounts, the notice given and the final invoice. 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: take-the-tool-on-and-hold-its-configuration description: Takes the tool on with its owner, its licence, its term and the process it runs, and holds the configuration at a version, so every change can be seen, dated and taken back. Use it when running `ref/rev/administer-a-tool`. license: CC-BY-4.0 metadata: agent: tool-administrator agent-version: "1" --- # Take the tool on and hold its configuration ## What it does Takes the tool on with its owner, its licence, its term and the process it runs, and holds the configuration at a version, so every change can be seen, dated and taken back. ## Where it happens The agent does this in two activities across one reference process. Each one names the activity as that process words it. - **Hold the Configuration at a Version** - `ref/rev/administer-a-tool`, activity 4 - [Administer a Tool](../../../../processes/revenue-operations/administer-a-tool.md) - **Take On the Tool** - `ref/rev/administer-a-tool`, activity 1 - [Administer a Tool](../../../../processes/revenue-operations/administer-a-tool.md) ## What to record The entry as it was taken on: the owner, the licence, the term and the process the tool runs. Every account open today with its role and its named approver, and every closure with its date and how long the account stood after the leaving record. The configuration at a version, each change carrying its date, the request behind it, what the trial away from live showed, and the way back that was kept. Each licence count setting licences paid for against licences used, naming every licence unused past the limit. Every refused request, with the reason and the process it belongs to. The review recorded with its decision, its date, the evidence it was made on and the date the next one falls. In a retirement: who was told and when, the export with everything the tool held that it could not take, every link stopped with what it was carrying, the read-only date, the closed accounts, the notice given and the final invoice. 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: wind-the-tool-down description: Tells the people who use it, stops new work going in, takes the export while the tool still runs, sees the process to its new home, stops the links, closes the accounts and the licence on the notice the agreement requires, and files what the retirement taught. Use it when running `ref/rev/retire-a-tool`. license: CC-BY-4.0 metadata: agent: tool-administrator agent-version: "1" --- # Wind the tool down ## What it does Tells the people who use it, stops new work going in, takes the export while the tool still runs, sees the process to its new home, stops the links, closes the accounts and the licence on the notice the agreement requires, and files what the retirement taught. ## Where it happens The agent does this in seven activities across one reference process. Each one names the activity as that process words it. - **Close the Accounts and the Licence** - `ref/rev/retire-a-tool`, activity 12 - [Retire a Tool](../../../../processes/revenue-operations/retire-a-tool.md) - **Move the Process to Its New Home** - `ref/rev/retire-a-tool`, activity 6 - [Retire a Tool](../../../../processes/revenue-operations/retire-a-tool.md) - **Record What Was Learned** - `ref/rev/retire-a-tool`, activity 15 - [Retire a Tool](../../../../processes/revenue-operations/retire-a-tool.md) - **Stop New Work Going In** - `ref/rev/retire-a-tool`, activity 10 - [Retire a Tool](../../../../processes/revenue-operations/retire-a-tool.md) - **Take the Export** - `ref/rev/retire-a-tool`, activity 7 - [Retire a Tool](../../../../processes/revenue-operations/retire-a-tool.md) - **Tell the People Who Use It** - `ref/rev/retire-a-tool`, activity 5 - [Retire a Tool](../../../../processes/revenue-operations/retire-a-tool.md) - **Turn Off the Links** - `ref/rev/retire-a-tool`, activity 9 - [Retire a Tool](../../../../processes/revenue-operations/retire-a-tool.md) ## What to record The entry as it was taken on: the owner, the licence, the term and the process the tool runs. Every account open today with its role and its named approver, and every closure with its date and how long the account stood after the leaving record. The configuration at a version, each change carrying its date, the request behind it, what the trial away from live showed, and the way back that was kept. Each licence count setting licences paid for against licences used, naming every licence unused past the limit. Every refused request, with the reason and the process it belongs to. The review recorded with its decision, its date, the evidence it was made on and the date the next one falls. In a retirement: who was told and when, the export with everything the tool held that it could not take, every link stopped with what it was carrying, the read-only date, the closed accounts, the notice given and the final invoice. 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: work-a-change-through-off-live-first description: Takes in what people ask for and what the supplier has changed, tries it away from live, and applies it with the way back kept. Use it when running `ref/rev/administer-a-tool`. license: CC-BY-4.0 metadata: agent: tool-administrator agent-version: "1" --- # Work a change through off live first ## What it does Takes in what people ask for and what the supplier has changed, tries it away from live, and applies it with the way back kept. A request that is not what the tool is for is refused in writing with the process it belongs to named. ## Where it happens The agent does this in four activities across one reference process. Each one names the activity as that process words it. - **Apply the Change** - `ref/rev/administer-a-tool`, activity 7 - [Administer a Tool](../../../../processes/revenue-operations/administer-a-tool.md) - **Take in Change Requests** - `ref/rev/administer-a-tool`, activity 5 - [Administer a Tool](../../../../processes/revenue-operations/administer-a-tool.md) - **Take in Supplier Changes** - `ref/rev/administer-a-tool`, activity 11 - [Administer a Tool](../../../../processes/revenue-operations/administer-a-tool.md) - **Try the Change away from Live** - `ref/rev/administer-a-tool`, activity 6 - [Administer a Tool](../../../../processes/revenue-operations/administer-a-tool.md) ## What to record The entry as it was taken on: the owner, the licence, the term and the process the tool runs. Every account open today with its role and its named approver, and every closure with its date and how long the account stood after the leaving record. The configuration at a version, each change carrying its date, the request behind it, what the trial away from live showed, and the way back that was kept. Each licence count setting licences paid for against licences used, naming every licence unused past the limit. Every refused request, with the reason and the process it belongs to. The review recorded with its decision, its date, the evidence it was made on and the date the next one falls. In a retirement: who was told and when, the export with everything the tool held that it could not take, every link stopped with what it was carrying, the read-only date, the closed accounts, the notice given and the final invoice. 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": {
"tool": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/tool"
},
"account-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/account-record"
},
"configuration-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/configuration-record"
},
"identity-system": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/identity-system"
},
"non-live-environment": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/non-live-environment"
},
"flow-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/flow-record"
},
"stack-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/stack-record"
},
"budget-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/budget-record"
}
}
}
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, 22 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 On the Tool · Set the Roles and the Permissions · Open and Close Accounts · Hold the Configuration at a Version · Take in Change Requests · Try the Change away from Live · Apply the Change · Keep the Licence Count Right · Take in Supplier Changes · Read Every Account Again · Run the Standing Review · Record the Review
Set the Access the Link Is Given · Switch It On · Hand It to the Administrator
Tell the People Who Use It · Move the Process to Its New Home · Take the Export · Turn Off the Links · Stop New Work Going In · Close the Accounts and the Licence · Record What Was Learned
What it writes down
The entry as it was taken on: the owner, the licence, the term and the process the tool runs. Every account open today with its role and its named approver, and every closure with its date and how long the account stood after the leaving record. The configuration at a version, each change carrying its date, the request behind it, what the trial away from live showed, and the way back that was kept. Each licence count setting licences paid for against licences used, naming every licence unused past the limit. Every refused request, with the reason and the process it belongs to. The review recorded with its decision, its date, the evidence it was made on and the date the next one falls. In a retirement: who was told and when, the export with everything the tool held that it could not take, every link stopped with what it was carrying, the read-only date, the closed accounts, the notice given and the final invoice.
What it will not do
Does not decide whether the tool stays. It brings the use, the cost, the findings and the supplier changes to the review, the stack-planner agent runs the review, and a named person decides. Does not set the roles and permissions on its own or clear the access review, which are human gates. Does not build or change the links either side, which is the integration-keeper agent. Does not choose a tool, negotiate a term or end an agreement on its own. Does not bend the tool to carry work it was not chosen for.
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: tool-administrator 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.
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,…
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.
- Container Host AIops MCP server · aiops-tools.github.io · run it yourself · mirrored from the MCP registry Governed Docker + Portainer container-host ops: reads, RCA analyses, guarded writes. 38 tools.
- gateway MCP server · blacklake.systems · hosted · run it yourself · mirrored from the MCP registry Governed MCP gateway: approval gates, signed audit receipts, and cost control for agent tool calls.
- mcp-server MCP server · decantr-ai.github.io · run it yourself · mirrored from the MCP registry Stable eight-tool MCP server for changed-UI assurance, authority-aware UI task context, and repair.