What can you do with this server?

The agent-services-mcp server is a unified MCP gateway exposing seven tools across three core services: content provenance certification, content quality scoring, and agent action auditing. Paid tools require an x402 micropayment; all paid tools return Ed25519-signed receipts that can be independently verified. Content Provenance * certify_provenance (paid) – Certifies content origin, returning an Ed25519-signed receipt with a SHA-256 hash and caller-attested metadata, proving the content is unmodified. * verify_provenance (free) – Re-hashes content and validates the signature of an existing provenance receipt. Content Quality * score_quality (paid) – Scores content against a published rubric across four dimensions (clarity, completeness, internal consistency, obvious-error freedom), returning a signed score receipt. Supports an optional target_score for "no pass, no pay" conditional payment. * verify_quality (free) – Validates the signature and content hash of a quality score receipt. * get_quality_rubric (free) – Fetches the current quality rubric in markdown format, including the rubric version and scoring criteria. Agent Action Auditing * audit_action (paid) – Creates a tamper-evident, Ed25519-signed audit receipt for an agent's claimed action, including actor metadata and context. * verify_audit (free) – Verifies the integrity and authenticity of an audit receipt. The server operates over stdio as an MCP server, supports configuration of underlying service URLs via environment variables, and forwards x402 payment tokens to upstream services without directly managing client wallets.

How do I use agent-services-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@agent-services-mcp show me the quality rubric" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

agent-services-mcp

by Gareth1953

Overview Schema Related Servers Score Discussions

JavaScript

Remote

agent-services-mcp

A single thin MCP (Model Context Protocol) server that exposes three existing services as discoverable tools, so AI agents and MCP-compatible clients can find and use them through one connection:

provenance-receipts — certifies content origin; returns an Ed25519-signed receipt.
quality-gate — scores content quality against a published rubric; returns an Ed25519-signed score receipt.
agent-action-audit — signs a tamper-evident audit receipt for an action an agent took (agent accountability); returns an Ed25519-signed audit receipt.

It is a thin wrapper. Every tool forwards an HTTP call to the underlying Worker and returns its response verbatim. It does not reimplement signing, scoring, or payment logic — those live in the underlying services. The honesty about what each service proves carries through to the tool descriptions.

Quickstart — your first (free) call in ~2 minutes

npm install && npm run build
node examples/free-call.mjs       # connects to the LIVE services and calls a free tool

examples/free-call.mjs runs an MCP client against this server (pointed at the live deployments) and calls get_quality_rubric and verify_audit — both free, no wallet needed. To wire the server into an MCP client (Claude Desktop / Claude Code style), see Connecting an MCP client below.

Free vs paid at a glance: verify_provenance, verify_quality, verify_audit, and get_quality_rubric are free. certify_provenance, score_quality, and audit_action are paid (an x402 USDC micropayment on Base) — see Calling paid tools for the two-step payment flow and a working example.

Related MCP server: protect-mcp

What the wrapped services prove (and do not)

Provenance: proves the content is unmodified (SHA-256 hash) and the receipt was issued by the service's key. The generator_metadata is caller-attested — it proves you claimed it, not that a specific model ran. Not AI-detection, not a truth guarantee.
Quality: a reproducible score against the published rubric (clarity, completeness, internal consistency, obvious-error freedom). Not absolute truth, not an external standard, not a fact-check. Read the rubric via the get_quality_rubric tool.
Audit: proves the action record is genuine (issued by the service's key) and unaltered since issue (tamper-evident). The action, actor_metadata, and context are caller-attested — it proves you claimed this record, not that the agent's claim is true. An accountability/audit tool, not a lie-detector.

Tools

Tool	Forwards to	Paid?	Input
`certify_provenance`	provenance-receipts `POST /v1/certify`	yes (x402)	`content` (string), `generator_metadata` (object, optional)
`verify_provenance`	provenance-receipts `POST /v1/verify`	no	`content` (string), `receipt` (object)
`score_quality`	quality-gate `POST /v1/score`	yes (x402)	`content` (string), `rubric_version` (string, optional), `target_score` (number 0–100, optional)
`verify_quality`	quality-gate `POST /v1/verify`	no	`content` (string), `receipt` (object)
`get_quality_rubric`	quality-gate `GET /v1/rubric`	no	none
`audit_action`	agent-action-audit `POST /v1/audit`	yes (x402)	`action` (string), `actor_metadata` (object), `context` (object, optional)
`verify_audit`	agent-action-audit `POST /v1/verify`	no	`action` (string), `actor_metadata` (object), `context` (object, optional), `receipt` (object)

Full descriptions and Zod input/output schemas: src/tools.ts. Each tool returns the service's raw JSON (or markdown, for the rubric) as text; the verify_* and score_quality tools also declare an outputSchema and return parsed structuredContent you can read directly (e.g. result.structuredContent.valid). A non-2xx response (including a 402 Payment Required) is surfaced with isError: true and the body preserved — for a 402 the wrapper prepends a short, actionable note on how to pay. The three paid tools also accept an optional x_payment input (the x402 X-PAYMENT token) to settle payment through the wrapper — see Calling paid tools.

Configuration

The three service URLs are environment-configurable (no secrets — just base URLs):

Env var	Live (deployed)	Local dev fallback
`PROVENANCE_URL`	`https://provenance-receipts.gpmiddleton71.workers.dev`	`http://localhost:8787`
`QUALITY_GATE_URL`	`https://quality-gate.gpmiddleton71.workers.dev`	`http://localhost:8788`
`AUDIT_URL`	`https://agent-action-audit.gpmiddleton71.workers.dev`	`http://localhost:8789`

.env.example and the client config below point at the live deployments. If the vars are unset, the server falls back to localhost for local wrangler dev (the Workers default to :8787, so run quality-gate on :8788 and agent-action-audit on :8789 to avoid clashes).

Against the live services, the paid tools (certify_provenance, score_quality, audit_action) require x402 — this wrapper forwards the request and holds no wallet, so without an X-PAYMENT they return a 402 (the payment requirements) surfaced as isError. The free tools work as normal.

Calling paid tools (x402)

The three paid tools require an x402 micropayment (USDC on Base mainnet). The wrapper holds no wallet — it never spends on your behalf — so paying is a two-step flow:

Call the tool with no x_payment. You get back a 402 whose body is the x402 payment requirements (network, asset, amount, payTo). The wrapper prepends a one-line note explaining what to do next.
Build an x402 X-PAYMENT token from those requirements with an x402 client + a funded wallet, then call the tool again with that token in the x_payment input. The wrapper forwards it as the X-PAYMENT header; the underlying service verifies, settles, and returns the signed receipt.

Easiest path to a working paid call — let an x402 client settle for you against the underlying service directly:

npm install x402-fetch
BUYER_PRIVATE_KEY=0x...  node examples/paid-call.mjs

examples/paid-call.mjs uses x402-fetch + a throwaway Base-mainnet wallet (holding a little real USDC) to pay for and call audit_action. ~$0.01 USDC moves buyer → the service's payTo, gasless (the facilitator pays gas). Real money — use a disposable key with a few cents only. The same applies to certify_provenance and score_quality.

Quickstart (local)

# 1. Build the MCP server
npm install
npm run build            # -> dist/index.js

# 2. In separate terminals, run the three services (free; payments off)
#    (provenance-receipts) npm run dev                 # http://localhost:8787
#    (quality-gate)        npx wrangler dev --port 8788 # http://localhost:8788
#    (agent-action-audit)  npx wrangler dev --port 8789 # http://localhost:8789

# 3a. Smoke-test the free tool paths through an MCP stdio client
node scripts/test-client.mjs

# 3b. (optional, costs ~$0.012) prove the paid score_quality path end-to-end
node scripts/test-score.mjs

# 3c. Smoke-test the wrapper against the LIVE deployed services (free — the
#     paid tools return a forwarded 402; no payment, no scoring call)
node scripts/test-live.mjs

scripts/test-client.mjs exercises the free tools locally; scripts/test-score.mjs makes one real Anthropic scoring call through score_quality; scripts/test-live.mjs points the wrapper at the deployed workers.dev URLs and asserts the free tools work and the paid tools forward the x402 402.

Connecting an MCP client (stdio)

This server speaks MCP over stdio (stdin/stdout). Any MCP client launches it as a subprocess. Example for a Claude Desktop / Claude Code style mcpServers config:

{
  "mcpServers": {
    "agent-services": {
      "command": "node",
      "args": ["C:\\Users\\Gareth\\agent-services-mcp\\dist\\index.js"],
      "env": {
        "PROVENANCE_URL": "https://provenance-receipts.gpmiddleton71.workers.dev",
        "QUALITY_GATE_URL": "https://quality-gate.gpmiddleton71.workers.dev",
        "AUDIT_URL": "https://agent-action-audit.gpmiddleton71.workers.dev"
      }
    }
  }
}

Run npm run build first so dist/index.js exists.
The client connects, calls tools/list (it will see the 7 tools above), and invokes them via tools/call.
The underlying services must be reachable at the configured URLs when a tool is called.
Logs go to stderr; stdout is reserved for the MCP protocol.

Programmatically, connect with the SDK's Client + StdioClientTransport (command: "node", args: ["dist/index.js"]) — see scripts/test-client.mjs.

x402 payments (forwarded, not handled here)

The paid endpoints (/v1/certify, /v1/score, /v1/audit) are gated by x402 on the underlying services. This wrapper forwards requests and does not hold a wallet. If a service has payments enabled and no valid X-PAYMENT is supplied, it returns 402 with the payment requirements — the wrapper surfaces that as isError with the requirements body intact. Settling a payment (signing an x402 authorization) is the client's responsibility against the underlying service. See each service's README.md / docs/API.md for the x402 details. Base Sepolia testnet only — no mainnet.

Verifying receipts independently

The receipts returned by certify_provenance, score_quality, and audit_action are Ed25519-signed and verifiable without trusting any of these services — re-hash the content/record and check the signature against the service's public key. Each service ships a runnable independent verifier and recipe: see provenance-receipts/docs/VERIFYING.md, quality-gate/docs/VERIFYING.md, and agent-action-audit's docs/VERIFYING.md.

Build status

Step 1 — skeleton + tool definitions (src/tools.ts)
Step 2 — tool handlers (HTTP forwarding) + local smoke test
Step 3 — README: what it is, the tools, and how an MCP client connects
Live — pointed at the deployed services (*.gpmiddleton71.workers.dev) and verified end-to-end via scripts/test-live.mjs: free tools work; paid tools forward the x402 402.

All seven tool paths verified against the live deployments (including one paid score_quality call end-to-end through the wrapper); the paid tools (certify_provenance, score_quality, audit_action) forward the x402 402.

Stack

Official MCP SDK: @modelcontextprotocol/sdk v1.29.0 (TypeScript), stdio transport, zod input schemas.
Node ESM + TypeScript (tsc → dist/).

Project layout

agent-services-mcp/
├── src/
│   ├── index.ts     # MCP server: registers tools, forwards HTTP, stdio transport
│   └── tools.ts     # the 7 tool definitions (names, descriptions, Zod schemas)
├── scripts/
│   ├── test-client.mjs  # MCP stdio client — free tool smoke test (local)
│   ├── test-score.mjs   # MCP stdio client — one paid score_quality e2e check
│   └── test-live.mjs    # MCP stdio client — against the live deployed services
├── package.json
├── tsconfig.json
├── .gitignore
└── .env.example     # PROVENANCE_URL, QUALITY_GATE_URL, AUDIT_URL

Available Tools

5 tools

certify_provenanceCertify content provenanceA

Certify the ORIGIN of a piece of content via the provenance-receipts service. Returns an Ed25519-signed receipt committing to a SHA-256 hash of the content, your caller-attested generator_metadata, and a service-set timestamp.

PROVES: the content is unmodified (hash) and the receipt was issued by the holder of the service's signing key. DOES NOT PROVE: it does not independently verify generator_metadata — the receipt proves you CLAIMED that metadata at certification time, not that a specific model actually produced the content. This is proof-of-origin/tamper-evidence, not AI-detection and not a truth guarantee.

Note: /v1/certify is the paid action; when the underlying service has x402 payments enabled it may require a micropayment. This wrapper forwards the request as-is.

ParametersJSON Schema

Name	Required	Description	Default
`content`	Yes	The exact content to certify. Non-empty.
`generator_metadata`	No	Optional caller-attested metadata about what generated the content (e.g. { model, provider }). Recorded verbatim; the receipt proves you claimed it, not that a specific model ran.

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It explains the cryptographic process (SHA-256 hash, Ed25519-signed receipt, timestamp), the nature of generator_metadata, and the payment requirement. It lacks details on error handling or response structure but provides solid behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and uses bold headers for key sections (PROVES, DOES NOT PROVE), improving readability. The payment note is integrated without bloating. A few redundant phrases could be trimmed, but overall it is well-structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains the returned receipt (Ed25519-signed) and its contents (hash, metadata, timestamp). It covers core functionality, limitations, and payment context. A more detailed return format would increase completeness, but it suffices for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, but the description adds meaning beyond the schema by clarifying that generator_metadata is recorded verbatim and that the receipt only proves the claim, not the actual model. This provides valuable context for parameter interpretation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool certifies content origin via a provenance service, distinguishing it from siblings like verify_provenance. It specifies the action (certify), the resource (content provenance), and details what the receipt proves and does not prove, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly guides usage by explaining what the tool does and does not prove, preventing misuse. It also mentions the paid action note with x402 payments. However, it does not explicitly compare to siblings like verify_provenance or provide when-not-to-use scenarios, leaving slight room for improvement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_quality_rubricGet the published quality rubricA

Fetch the published Quality Gate rubric (markdown) that score_quality grades against, along with its version. Read this to understand exactly what a quality score means and does not mean. Free; takes no input.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Mentions 'Free; takes no input.' but omits details like caching, authentication, or whether it updates. Adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two clear sentences: one stating action, another adding usage guidance and input status. No fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, description explains returns (rubric markdown plus version). Could elaborate on version meaning, but satisfies most needs for a simple fetch tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist; description confirms 'takes no input.' Details about the output (markdown and version) provide meaning beyond the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states fetching the published Quality Gate rubric and version, distinguishing it from siblings like score_quality or verify_quality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises reading to understand what a quality score means and does not mean, implying when to use. Lacks explicit exclusions or alternatives, but context with sibling tools makes usage clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

score_qualityScore content against the published quality rubricA

Score content against the quality-gate service's PUBLISHED rubric and get an Ed25519-signed score receipt. The rubric scores four dimensions — clarity, completeness, internal consistency, and obvious-error freedom (0–25 each, summing to 0–100) — plus flags from a closed vocabulary. Read the exact rubric with get_quality_rubric.

WHAT THIS IS: a reproducible score AGAINST OUR PUBLISHED RUBRIC (vX). WHAT IT IS NOT: a measure of absolute truth, an external/third-party standard, or a fact-check — 'obvious-error freedom' catches errors evident from the text or common knowledge, not external verification.

Optional target_score (0–100) enables 'no pass, no pay': if the score is below your target, no receipt is issued and (when payments are on) no charge is made — the response returns the failing breakdown with receipt: null.

Note: /v1/score is the paid action (one Claude API scoring pass per call) and may require an x402 micropayment when the underlying service has payments enabled.

ParametersJSON Schema

Name	Required	Description
`content`	Yes	The content to score. Non-empty.
`rubric_version`	No	Optional rubric version to score against; must match the service's current version (e.g. "v1") if provided.
`target_score`	No	Optional 0–100 threshold. Enables 'no pass, no pay': below this, no receipt is issued and no charge is made.

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully carries the burden. It discloses that the output is an Ed25519-signed score receipt, explains the effect of target_score on receipt issuance and charges, and mentions potential micropayment requirements. No contradictions exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is clear and structured with sections (WHAT THIS IS, WHAT IT IS NOT, etc.), but is slightly verbose with some redundancy (e.g., repeating 'score content'). Front-loaded effectively with the main purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers key aspects: scoring dimensions, receipt signing, optional features, and payment notes. However, it does not fully detail the return structure beyond mentioning a signed receipt and breakdown. Given no output schema, slightly more specificity could help, but it is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, but the description adds significant value beyond the schema. It explains that rubric_version must match the service's current version if provided, and describes the target_score's 'no pass, no pay' mechanism in detail, which is not in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool scores content against a published quality rubric, listing the four dimensions (clarity, completeness, internal consistency, obvious-error freedom) and the score range. It distinguishes itself from sibling tools like get_quality_rubric (which reads the rubric) and implies it is the scoring action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states what the tool is and is not, and explains the optional target_score parameter's 'no pass, no pay' behavior. It also notes the /v1/score endpoint is the paid action and may require micropayments, helping agents decide when to use the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_provenanceVerify a provenance receiptA

Verify a provenance receipt against its content via provenance-receipts. Re-hashes the content and checks the Ed25519 signature; returns { valid, details }. valid is true only if BOTH the content hash matches the receipt AND the signature is valid under the service's public key. Free. A 200 response means verification ran — always read valid (false means the content was modified or the receipt was altered/forged).

ParametersJSON Schema

Name	Required	Description	Default
`content`	Yes	The content to check against the receipt.
`receipt`	Yes	A provenance receipt as returned by certify_provenance.

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description fully explains the verification process (re-hashing content, checking Ed25519 signature, return shape with valid and details), including what valid means and how to interpret failures. It also clarifies that a 200 response does not guarantee validity. No annotations were provided, so the description carries the full burden and meets it excellently.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured paragraph that front-loads the action and includes all necessary details without redundancy. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite lacking an output schema, the description comprehensively covers the return structure and meaning. All parameters are clearly documented, and the tool's behavior is fully described, making it complete for its complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with clear parameter descriptions. The description adds value by explaining the verification process and linking the receipt parameter to certify_provenance, providing context beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool verifies a provenance receipt against its content, with a specific verb 'verify' and resource 'provenance receipt'. It is distinct from sibling tools like certify_provenance (which creates receipts) and those for quality scoring, leaving no ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (after obtaining a receipt from certify_provenance) but does not explicitly state when to use or when not to use, nor mention alternatives. It provides no exclusions, so guidance is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_qualityVerify a quality score receiptA

Verify a quality score receipt against its content via quality-gate. Re-hashes the content and checks the Ed25519 signature, which covers the score itself — so a forged or altered score fails. Returns { valid, details }. Free. A 200 response means verification ran — always read valid.

ParametersJSON Schema

Name	Required	Description	Default
`content`	Yes	The content the score receipt was issued for.
`receipt`	Yes	A quality score receipt as returned by score_quality.

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description fully discloses the verification process: re-hashing content, checking Ed25519 signature, handling forged/altered scores, return format ({valid, details}), cost (free), and HTTP response interpretation (200 means ran, always read 'valid'). No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each purposeful. Front-loaded with the core purpose, then technical details, then practical usage note. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a verification tool with no output schema, the description covers the return shape, HTTP response nuance, cost, and security mechanism. It is complete and self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining that receipt comes from 'score_quality' and detailing the verification mechanism, going beyond the schema's basic property descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool verifies a quality score receipt against its content using a quality-gate, with specific details about re-hashing and Ed25519 signature checking. It distinguishes from sibling tools like verify_provenance by focusing on quality scores.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides some context (e.g., free, 200 response meaning) but does not explicitly state when to use this tool over alternatives like verify_provenance. No exclusions or alternate tool mentions are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0

Disambiguation5/5

Each tool has a distinct purpose: certifying provenance, fetching the quality rubric, scoring quality, and verifying receipts for both provenance and quality. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., certify_provenance, verify_quality), making the set predictable and easy to navigate.

Tool Count5/5

With only 5 tools, the set is well-scoped for the domain of provenance and quality attestation. Each tool earns its place, covering core actions without unnecessary bloat.

Completeness5/5

The tool surface covers the full workflow: certification, scoring with a rubric, and verification for both. There are no obvious gaps for the stated purpose of provenance and quality assurance.

Maintenance

ActivityStale

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Word Of Clout ACN MCP Server
io.github.wordofclout
Guarded MCP server for agent-readable business truth, provenance, readiness, and discovery.
CRM Customer Data Platforms
2
Bay Run A
io.github.barneywohl
Free OpenAI-compatible inference with signed provenance receipts and 3 focused MCP tools.
AI & Machine Learning RAG Systems
31
Reasoning Commons
io.github.chenyuan35
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
AI & Machine Learning Knowledge & Memory Autonomous Agents
2
mcp AOAuth
io.scorecard
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
RAG Systems Monitoring Testing & QA Tools
3

Related MCP Servers

aip-identity
Autonomous Agents Security
The-Nexus-Guard
A
license
A
quality
D
maintenance
MCP server for AI agent identity — verify agents with Ed25519 signatures, check trust scores, sign and verify content, exchange encrypted messages. Built on the Agent Identity Protocol (AIP).
Updated 6 months ago (2026-03-09 12:03 UTC)
8
MIT
protect-mcp
Security Developer Tools
tomjwxf
A
license
B
quality
C
maintenance
Security gateway that wraps any MCP server with per-tool policies, approval gates, and optional Ed25519-signed decision receipts. Shadow mode logs every tool call without blocking; enforce mode applies block, rate-limit, and minimum-tier rules. Receipts are independently verifiable offline with no accounts needed.
Updated 2 months ago (2026-07-03 05:22 UTC)
5
693
10
MIT
Agent Identity MCP Server
Security Autonomous Agents
AiAgentKarl
A
license
Not graded
quality
D
maintenance
MCP Server for AI agent identity and authorization. Create, verify, and manage agent identities with trust scores and scoped authorization tokens.
Updated 5 months ago (2026-04-03 16:05 UTC)
MIT
contextboundary-gw
Security Developer Tools
kannanokannan
A
license
Not graded
quality
B
maintenance
Self-hosted MCP gateway that applies deterministic, compiled policy to tool discovery, invocation, and outbound data flow, with no model in the enforcement path. Every decision emits a hash-chained receipt sealed with Ed25519 and verifiable using public keys only.
Updated 2 days ago (2026-09-01 23:54 UTC)
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Gareth1953/agent-services-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server