Sign in
abstract agent · sales · 2 processes · plugin 1.0.0

Order check

order-check v1

Turns an executed agreement into a booking the rest of the company can act on, and refuses one that does not match. Lifts the terms, the dates and the prices out of the paper into fields, each field naming the clause it came from, then tests the result three ways: every line against the price book, every line against something that exists in the catalog, and every date against what the delivery side can actually meet. A booking that fails goes back to be corrected rather than forward to an approver. It is the agent that stops a company promising what it cannot deliver.

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.

WORKS INref/sls/book-the-orderref/sls/hand-over-to-deliveryGRANTEDthe contract repositoryread — every booking field names the clause itthe price bookread — each line priced at a named version, orthe product catalogread — every sold line matched to something thdelivery capacity recordsread — whether the date the customer expects cthe order systemwrite — the booking, at the version an approvethe CRMwrite — the opportunity closed at the booked athe billing systemwrite — the billing schedule, the payment termthe forecastwrite — corrected to what was actually booked THE ABSTRACT AGENTorder-checkv1turns an executed…HANDS TO A PERSONa line the delivery side…a person decidesa booking that fails its…a person decidesa booking changed after…a person decidesan order system that will…a person decidesa handover package missing…a person decidesMUST FOLLOWcollect-and-reportapprovalassessment

Runs assessment three times: on every sold line against a catalog item, a delivery date and the capacity to meet it; on the whole booking against the booking rules at a version; and on the handover package against its checklist. Runs collect-and-report over the exceptions it raises for as long as a booking is open. Requests the approval a finance approver signs, and takes the booking back through it when anything changes after. Takes the executed agreement and the settled non-standard terms from the signature-manager agent, waits on the credit reading from the account-monitor agent, and hands the booked order to the handover-coordinator agent.

The plugin

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.

order-check · 10 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 sign the booking. Finance approval is a human gate, and this
agent prepares the booking for it and records what was signed. Does not
approve an exception or settle a term off the standard paper: those are
named and routed by the signature-manager agent to the people who may
sign them. Does not build a configuration or set a price, which are the
configurator and quote-builder agents' work before an agreement exists.
Does not own the customer relationship after the booking, which passes
to the handover-coordinator agent.

## What always goes to a person

- a line the delivery side cannot deliver as sold, to the delivery lead
  and the deal desk, with the date and what can be delivered instead,
  before the line is booked
- a booking that fails its check, back to the terms with the rule
  attached to each failure, rather than on to an approver
- a booking changed after finance approved it, back through approval,
  because the approval covered a version
- an order system that will not take the booking, to whoever owns that
  system, with the booking held at its approved version rather than half
  written
- a handover package missing what its checklist requires, to the
  handover coordinator, carried forward as a named gap with a date
  rather than waived quietly
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 `order-check` leaves the
following behind, on every run.

Per booking: each field with the clause it was read from. The start,
end, notice and renewal dates with the clause that set each one, and any
date the paper leaves ambiguous named as ambiguous. Every line with its
catalog item, its quantity and its price at a price book version, or the
approval that let it differ. The deliverability check line by line,
naming what cannot be delivered as sold and what can be delivered
instead. The score against the booking rules at a version, with the rule
behind every failure and the written acceptance carrying any failure
forward. The approver, the date, and the version they signed. The
billing schedule as finance accepted it. The handover package scored
against its checklist version, naming what is missing rather than what
is present.

An agent that leaves less than this does not implement `order-check`,
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

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 contract repository | read | Every booking field names the clause it was read from. |
| the price book | read | Each line priced at a named version, or naming the approval that let it differ. |
| the product catalog | read | Every sold line matched to something that exists. |
| delivery capacity records | read | Whether the date the customer expects can be met. |
| the order system | write | The booking, at the version an approver signed and no other. |
| the CRM | write | The opportunity closed at the booked amount. |
| the billing system | write | The billing schedule, the payment terms and the purchase order reference. |
| the forecast | write | Corrected to what was actually booked rather than to what was forecast. |

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": "order-check",
  "version": "1.0.0",
  "description": "The order-check abstract agent. Turns an executed agreement into a booking the rest of the company can act on, and refuses one that does not match.",
  "author": {
    "name": "AgentCatalog",
    "url": "https://agentcatalog.com"
  },
  "homepage": "https://agentcatalog.com/abstract-agents/order-check",
  "repository": "https://github.com/jeffrschneider/agentcatalog",
  "license": "CC-BY-4.0",
  "keywords": [
    "abstract-agent",
    "reference",
    "sales",
    "book-the-order",
    "hand-over-to-delivery",
    "abstract"
  ],
  "extensions": {
    "com.agentcatalog.agent": {
      "agent": "order-check",
      "agentVersion": 1,
      "department": "sales",
      "abstract": true,
      "works": "Runs assessment three times: on every sold line against a catalog item, a delivery date and the capacity to meet it; on the whole booking against the booking rules at a version; and on the handover package against its checklist. Runs collect-and-report over the exceptions it raises for as long as a booking is open. Requests the approval a finance approver signs, and takes the booking back through it when anything changes after. Takes the executed agreement and the settled non-standard terms from the signature-manager agent, waits on the credit reading from the account-monitor agent, and hands the booked order to the handover-coordinator agent.",
      "servers": [
        {
          "name": "the contract repository",
          "role": "contract-repository",
          "access": "read",
          "needs": "Every booking field names the clause it was read from."
        },
        {
          "name": "the price book",
          "role": "price-book",
          "access": "read",
          "needs": "Each line priced at a named version, or naming the approval that let it differ."
        },
        {
          "name": "the product catalog",
          "role": "product-catalog",
          "access": "read",
          "needs": "Every sold line matched to something that exists."
        },
        {
          "name": "delivery capacity records",
          "role": "delivery-capacity-records",
          "access": "read",
          "needs": "Whether the date the customer expects can be met."
        },
        {
          "name": "the order system",
          "role": "order-system",
          "access": "write",
          "needs": "The booking, at the version an approver signed and no other."
        },
        {
          "name": "the CRM",
          "role": "crm",
          "access": "write",
          "needs": "The opportunity closed at the booked amount."
        },
        {
          "name": "the billing system",
          "role": "billing-system",
          "access": "write",
          "needs": "The billing schedule, the payment terms and the purchase order reference."
        },
        {
          "name": "the forecast",
          "role": "forecast",
          "access": "write",
          "needs": "Corrected to what was actually booked rather than to what was forecast."
        }
      ],
      "records": [
        "Per booking: each field with the clause it was read from.",
        "The start, end, notice and renewal dates with the clause that set each one, and any date the paper leaves ambiguous named as ambiguous.",
        "Every line with its catalog item, its quantity and its price at a price book version, or the approval that let it differ.",
        "The deliverability check line by line, naming what cannot be delivered as sold and what can be delivered instead.",
        "The score against the booking rules at a version, with the rule behind every failure and the written acceptance carrying any failure forward.",
        "The approver, the date, and the version they signed.",
        "The billing schedule as finance accepted it.",
        "The handover package scored against its checklist version, naming what is missing rather than what is present."
      ],
      "escalates": [
        "a line the delivery side cannot deliver as sold, to the delivery lead and the deal desk, with the date and what can be delivered instead, before the line is booked",
        "a booking that fails its check, back to the terms with the rule attached to each failure, rather than on to an approver",
        "a booking changed after finance approved it, back through approval, because the approval covered a version",
        "an order system that will not take the booking, to whoever owns that system, with the booking held at its approved version rather than half written",
        "a handover package missing what its checklist requires, to the handover coordinator, carried forward as a named gap with a date rather than waived quietly"
      ],
      "not": [
        "Does not sign the booking.",
        "Finance approval is a human gate, and this agent prepares the booking for it and records what was signed.",
        "Does not approve an exception or settle a term off the standard paper: those are named and routed by the signature-manager agent to the people who may sign them.",
        "Does not build a configuration or set a price, which are the configurator and quote-builder agents' work before an agreement exists.",
        "Does not own the customer relationship after the booking, which passes to the handover-coordinator agent."
      ],
      "processes": [
        {
          "process": "ref/sls/book-the-order",
          "activities": [
            "Read the Terms into a Booking",
            "Set the Term and the Dates",
            "Price the Booking",
            "Check What Was Sold Against What Exists",
            "Score the Booking",
            "Get Finance Approval",
            "Record the Booking",
            "Pass the Billing Terms to Finance",
            "Close the Opportunity"
          ]
        },
        {
          "process": "ref/sls/hand-over-to-delivery",
          "activities": [
            "Take in the Booked Order",
            "Check the Package Is Complete"
          ]
        }
      ]
    }
  }
}
README.mdWhat the package is, and why it carries no mcp.json.
# order-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/sls/book-the-order`, `ref/sls/hand-over-to-delivery`. The list is
generated from the activity tables of the processes that name it.

https://agentcatalog.com/abstract-agents/order-check
skills/check-the-handover-package/SKILL.mdTakes the booked order in and scores the handover package against its checklist at a version, naming what is missing rather than what is present. Use it when running `ref/sls/hand-over-to-delivery`.
---
name: check-the-handover-package
description: Takes the booked order in and scores the handover package against its checklist at a version, naming what is missing rather than what is present. Use it when running `ref/sls/hand-over-to-delivery`.
license: CC-BY-4.0
metadata:
  agent: order-check
  agent-version: "1"
---

# Check the handover package

## What it does

Takes the booked order in and scores the handover package against its
checklist at a version, naming what is missing rather than what is
present. A gap is carried forward with a date rather than waived
quietly.

## Where it happens

The agent does this in two activities across one reference process. Each
one names the activity as that process words it.

- **Check the Package Is Complete**
  - `ref/sls/hand-over-to-delivery`, activity 9 -
    [Hand over to Delivery](../../../../processes/sales/hand-over-to-delivery.md)
- **Take in the Booked Order**
  - `ref/sls/hand-over-to-delivery`, activity 1 -
    [Hand over to Delivery](../../../../processes/sales/hand-over-to-delivery.md)

## What to record

Per booking: each field with the clause it was read from. The start,
end, notice and renewal dates with the clause that set each one, and any
date the paper leaves ambiguous named as ambiguous. Every line with its
catalog item, its quantity and its price at a price book version, or the
approval that let it differ. The deliverability check line by line,
naming what cannot be delivered as sold and what can be delivered
instead. The score against the booking rules at a version, with the rule
behind every failure and the written acceptance carrying any failure
forward. The approver, the date, and the version they signed. The
billing schedule as finance accepted it. The handover package scored
against its checklist version, naming what is missing rather than what
is present.

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/get-the-booking-approved/SKILL.mdPuts the booking in front of the finance approver at a version and records who signed it and when. Use it when running `ref/sls/book-the-order`.
---
name: get-the-booking-approved
description: Puts the booking in front of the finance approver at a version and records who signed it and when. Use it when running `ref/sls/book-the-order`.
license: CC-BY-4.0
metadata:
  agent: order-check
  agent-version: "1"
---

# Get the booking approved

## What it does

Puts the booking in front of the finance approver at a version and
records who signed it and when. A booking that changes afterwards goes
back through approval, because the approval covered a version.

## Where it happens

The agent does this in one activity across one reference process. Each
one names the activity as that process words it.

- **Get Finance Approval**
  - `ref/sls/book-the-order`, activity 11 -
    [Book the Order](../../../../processes/sales/book-the-order.md)

## What to record

Per booking: each field with the clause it was read from. The start,
end, notice and renewal dates with the clause that set each one, and any
date the paper leaves ambiguous named as ambiguous. Every line with its
catalog item, its quantity and its price at a price book version, or the
approval that let it differ. The deliverability check line by line,
naming what cannot be delivered as sold and what can be delivered
instead. The score against the booking rules at a version, with the rule
behind every failure and the written acceptance carrying any failure
forward. The approver, the date, and the version they signed. The
billing schedule as finance accepted it. The handover package scored
against its checklist version, naming what is missing rather than what
is present.

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/read-the-paper-into-a-booking/SKILL.mdLifts the terms out of the executed agreement into fields, each field naming the clause it came from, and sets the start, end, notice and renewal dates against the clause that fixed each one. Use it when running `ref/sls/book-the-order`.
---
name: read-the-paper-into-a-booking
description: Lifts the terms out of the executed agreement into fields, each field naming the clause it came from, and sets the start, end, notice and renewal dates against the clause that fixed each one. Use it when running `ref/sls/book-the-order`.
license: CC-BY-4.0
metadata:
  agent: order-check
  agent-version: "1"
---

# Read the paper into a booking

## What it does

Lifts the terms out of the executed agreement into fields, each field
naming the clause it came from, and sets the start, end, notice and
renewal dates against the clause that fixed each one. A date the paper
leaves open is named as open rather than guessed.

## Where it happens

The agent does this in two activities across one reference process. Each
one names the activity as that process words it.

- **Read the Terms into a Booking**
  - `ref/sls/book-the-order`, activity 4 -
    [Book the Order](../../../../processes/sales/book-the-order.md)
- **Set the Term and the Dates**
  - `ref/sls/book-the-order`, activity 5 -
    [Book the Order](../../../../processes/sales/book-the-order.md)

## What to record

Per booking: each field with the clause it was read from. The start,
end, notice and renewal dates with the clause that set each one, and any
date the paper leaves ambiguous named as ambiguous. Every line with its
catalog item, its quantity and its price at a price book version, or the
approval that let it differ. The deliverability check line by line,
naming what cannot be delivered as sold and what can be delivered
instead. The score against the booking rules at a version, with the rule
behind every failure and the written acceptance carrying any failure
forward. The approver, the date, and the version they signed. The
billing schedule as finance accepted it. The handover package scored
against its checklist version, naming what is missing rather than what
is present.

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/test-the-booking-against-the-record/SKILL.mdPrices every line at a price book version or names the approval that let it differ, matches every sold line to something that exists and to a date the delivery side can meet, and scores the whole booking against the booking rules at a version. Use it when running `ref/sls/book-the-order`.
---
name: test-the-booking-against-the-record
description: Prices every line at a price book version or names the approval that let it differ, matches every sold line to something that exists and to a date the delivery side can meet, and scores the whole booking against the booking rules at a version. Use it when running `ref/sls/book-the-order`.
license: CC-BY-4.0
metadata:
  agent: order-check
  agent-version: "1"
---

# Test the booking against the record

## What it does

Prices every line at a price book version or names the approval that let
it differ, matches every sold line to something that exists and to a
date the delivery side can meet, and scores the whole booking against
the booking rules at a version. A booking that fails goes back to be
corrected.

## Where it happens

The agent does this in three activities across one reference process.
Each one names the activity as that process words it.

- **Check What Was Sold Against What Exists**
  - `ref/sls/book-the-order`, activity 8 -
    [Book the Order](../../../../processes/sales/book-the-order.md)
- **Price the Booking**
  - `ref/sls/book-the-order`, activity 6 -
    [Book the Order](../../../../processes/sales/book-the-order.md)
- **Score the Booking**
  - `ref/sls/book-the-order`, activity 10 -
    [Book the Order](../../../../processes/sales/book-the-order.md)

## What to record

Per booking: each field with the clause it was read from. The start,
end, notice and renewal dates with the clause that set each one, and any
date the paper leaves ambiguous named as ambiguous. Every line with its
catalog item, its quantity and its price at a price book version, or the
approval that let it differ. The deliverability check line by line,
naming what cannot be delivered as sold and what can be delivered
instead. The score against the booking rules at a version, with the rule
behind every failure and the written acceptance carrying any failure
forward. The approver, the date, and the version they signed. The
billing schedule as finance accepted it. The handover package scored
against its checklist version, naming what is missing rather than what
is present.

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/write-the-booking-where-it-is-acted-on/SKILL.mdWrites the approved booking into the order system, passes the billing schedule, the payment terms and the purchase order reference to finance, and closes the opportunity at the amount actually booked rather than the amount forecast. Use it when running `ref/sls/book-the-order`.
---
name: write-the-booking-where-it-is-acted-on
description: Writes the approved booking into the order system, passes the billing schedule, the payment terms and the purchase order reference to finance, and closes the opportunity at the amount actually booked rather than the amount forecast. Use it when running `ref/sls/book-the-order`.
license: CC-BY-4.0
metadata:
  agent: order-check
  agent-version: "1"
---

# Write the booking where it is acted on

## What it does

Writes the approved booking into the order system, passes the billing
schedule, the payment terms and the purchase order reference to finance,
and closes the opportunity at the amount actually booked rather than the
amount forecast.

## Where it happens

The agent does this in three activities across one reference process.
Each one names the activity as that process words it.

- **Close the Opportunity**
  - `ref/sls/book-the-order`, activity 14 -
    [Book the Order](../../../../processes/sales/book-the-order.md)
- **Pass the Billing Terms to Finance**
  - `ref/sls/book-the-order`, activity 13 -
    [Book the Order](../../../../processes/sales/book-the-order.md)
- **Record the Booking**
  - `ref/sls/book-the-order`, activity 12 -
    [Book the Order](../../../../processes/sales/book-the-order.md)

## What to record

Per booking: each field with the clause it was read from. The start,
end, notice and renewal dates with the clause that set each one, and any
date the paper leaves ambiguous named as ambiguous. Every line with its
catalog item, its quantity and its price at a price book version, or the
approval that let it differ. The deliverability check line by line,
naming what cannot be delivered as sold and what can be delivered
instead. The score against the booking rules at a version, with the rule
behind every failure and the written acceptance carrying any failure
forward. The approver, the date, and the version they signed. The
billing schedule as finance accepted it. The handover package scored
against its checklist version, naming what is missing rather than what
is present.

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 8 roles, and the access level beside each one is the most the work needs.

contract-repository · readprice-book · readproduct-catalog · readdelivery-capacity-records · readorder-system · writecrm · writebilling-system · writeforecast · 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"
    },
    "price-book": {
      "type": "streamable-http",
      "url": "https://mcp.yourcompany.com/price-book"
    },
    "product-catalog": {
      "type": "streamable-http",
      "url": "https://mcp.yourcompany.com/product-catalog"
    },
    "delivery-capacity-records": {
      "type": "streamable-http",
      "url": "https://mcp.yourcompany.com/delivery-capacity-records"
    },
    "order-system": {
      "type": "streamable-http",
      "url": "https://mcp.yourcompany.com/order-system"
    },
    "crm": {
      "type": "streamable-http",
      "url": "https://mcp.yourcompany.com/crm"
    },
    "billing-system": {
      "type": "streamable-http",
      "url": "https://mcp.yourcompany.com/billing-system"
    },
    "forecast": {
      "type": "streamable-http",
      "url": "https://mcp.yourcompany.com/forecast"
    }
  }
}

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

2 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
12345678910111213141516

Read the Terms into a Booking · Set the Term and the Dates · Price the Booking · Check What Was Sold Against What Exists · Score the Booking · Get Finance Approval · Record the Booking · Pass the Billing Terms to Finance · Close the Opportunity

Hand over to Deliveryref/sls/hand-over-to-delivery · 16 activities
12345678910111213141516

Take in the Booked Order · Check the Package Is Complete

The records it leaves

What it writes down

Per booking: each field with the clause it was read from. The start, end, notice and renewal dates with the clause that set each one, and any date the paper leaves ambiguous named as ambiguous. Every line with its catalog item, its quantity and its price at a price book version, or the approval that let it differ. The deliverability check line by line, naming what cannot be delivered as sold and what can be delivered instead. The score against the booking rules at a version, with the rule behind every failure and the written acceptance carrying any failure forward. The approver, the date, and the version they signed. The billing schedule as finance accepted it. The handover package scored against its checklist version, naming what is missing rather than what is present.

Where it stops

What it will not do

Does not sign the booking. Finance approval is a human gate, and this agent prepares the booking for it and records what was signed. Does not approve an exception or settle a term off the standard paper: those are named and routed by the signature-manager agent to the people who may sign them. Does not build a configuration or set a price, which are the configurator and quote-builder agents' work before an agreement exists. Does not own the customer relationship after the booking, which passes to the handover-coordinator agent.

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: order-check 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.

  • 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.
  • fahali MCP server · fahaliai.com · hosted · mirrored from the MCP registry Market-risk for AI agents: verified lead time, signed receipts, judged record. Not advice.
  • Document Integrity Validator MCP server · ojaskord.github.io · hosted · run it yourself · mirrored from the MCP registry AI reasoning checks any document against known international standards before your agent acts on it.