A2A Artifact Handoff

Server Details

Compiles source-agent outputs into validated, receiver-ready handoff packages.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-06 03:36
Transport: Streamable HTTP
URL

Available Tools

3 tools

compile_handoffCInspect

Compile source-agent outputs into a receiver-ready handoff package.

The input schema declares the exact source-output, receiver-contract, and handoff-context fields. The tool selects and validates required deliverables and returns either a portable package or actionable unmet requirements.

ParametersJSON Schema

Name	Required	Description	Default
`ttl_hours`	No
`source_outputs`	Yes
`handoff_context`	Yes
`receiver_contract`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior3/5

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

There are no annotations, so the description carries the full burden. It does disclose a meaningful behavior: 'selects and validates required deliverables and returns either a portable package or actionable unmet requirements.' This tells the agent that validation can fail and the output may be a requirements list rather than a package. However, it does not mention side effects, permissions, or whether source outputs are left intact.

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?

Three sentences with no filler; the primary action is front-loaded. The middle sentence about the input schema is somewhat meta but compact. Overall it is concise and readable, though the second sentence could be considered redundant since the schema is visible to the agent.

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

Completeness2/5

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

For a tool with four parameters, three required nested objects, and no annotations, the description is thin. It does not explain how to construct source_outputs, what a receiver_contract is, or what handoff_context must contain. An output schema exists, so return values are covered, but correct invocation of a contract-driven tool would need more context than this description provides.

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

Parameters2/5

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

Schema description coverage is 0% for top-level parameters, so the description should compensate. It only says the schema declares 'source-output, receiver-contract, and handoff-context fields' without explaining what they mean, how they relate, or what values are expected. This adds little beyond pointing back at the schema.

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

Purpose4/5

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

The description opens with a specific verb–resource pair: 'Compile source-agent outputs into a receiver-ready handoff package.' This clearly identifies the operation and its product. It does not explicitly contrast itself with sibling tools inspect_handoff or prepare_artifact, so it misses the top score, but the compilation role is unmistakable.

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

Usage Guidelines2/5

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

No guidance is given about when to choose this tool over the siblings. The description implies a packaging scenario but does not state prerequisites, exclusions, or alternatives. With siblings like inspect_handoff and prepare_artifact present, the absence of routing guidance is a notable gap.

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

inspect_handoffAInspect

Inspect a handoff package and return an acceptance decision.

The tool recalculates deliverable hashes, checks expiry and contract satisfaction, and returns the receiving agent's next action.

ParametersJSON Schema

Name	Required	Description	Default
`run_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden and it delivers: it discloses the exact behavioral steps (recalculating hashes, checking expiry and contract satisfaction) and the outcome (next action for the receiving agent). The only gap is whether inspecting consumes or invalidates the handoff package, which matters in a handoff workflow.

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?

Two efficiently written sentences, front-loaded with the core purpose and followed by the behavioral specifics. Every sentence earns its place with no filler; only the missing run_id guidance keeps it from being optimal.

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 output schema exists, so the description correctly avoids re-explaining return values. For a validation tool with one parameter and known siblings, it covers the operation's substance well. The main remaining gap is the undocumented run_id parameter, which is modest for a tool this simple.

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

Parameters2/5

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

Schema description coverage is 0%, so the description should compensate for the lone run_id parameter, but it never mentions run_id or its format/meaning. While 'run_id' is arguably self-explanatory, the description adds zero semantics beyond the schema's bare 'Run Id' title — a missed opportunity for a single-parameter tool.

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?

States a specific verb (inspect) plus resource (handoff package) and the concrete outcome (acceptance decision). The second sentence names the exact validation steps — recalculation of deliverable hashes, expiry check, contract satisfaction — which clearly distinguishes it from siblings compile_handoff (creation) and prepare_artifact (packaging).

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 purpose implies usage: an agent can reasonably infer this is the validation gate before accepting a handoff, distinct from creating one. However, no sibling is named explicitly and there is no 'use X instead when...' routing. Context makes the role clear, but the alternative is left to inference rather than being stated.

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

prepare_artifactBInspect

Prepare content for transfer to another agent or a human reviewer.

`target_modes` accepts either a JSON list or an actual list of MIME types.
The result includes expiring artifact URLs, SHA-256 hashes, a manifest,
and a downloadable ZIP package.

ParametersJSON Schema

Name	Required	Default
`content`	Yes
`filename`	No	artifact.md
`ttl_hours`	No
`media_type`	No	text/markdown
`target_modes`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/5.0

Behavior3/5

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

With no annotations, the description carries the burden of behavioral disclosure. It usefully reveals that the result includes expiring artifact URLs, SHA-256 hashes, a manifest, and a ZIP package. However, it doesn't mention whether content persists, any authentication constraints, side effects, or limits such as TTL ranges.

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 compact and front-loaded. The purpose statement leads, the parameter clarification is relevant and concise, and the output summary is dense with useful detail. There is no filler.

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

Completeness3/5

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

The description covers the core purpose and key outputs, and an output schema exists to document return shape. However, it omits important behavioral and parameter context such as content formatting, TTL semantics, media_type handling, and usage boundaries. Given five parameters and zero parameter schema descriptions, this is only partially complete.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It only clarifies target_modes, explaining that it accepts a JSON list or an actual list of MIME types. The other four parameters — content, filename, ttl_hours, and media_type — receive no explanation beyond schema defaults.

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

Purpose4/5

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

The description states a clear verb and resource: 'Prepare content for transfer to another agent or a human reviewer.' It also distinguishes itself via specific outputs (expiring URLs, hashes, manifest, ZIP), which helps differentiate it from sibling tools like compile_handoff and inspect_handoff even though they aren't named.

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

Usage Guidelines2/5

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

There is no explicit guidance on when to use prepare_artifact versus compile_handoff or inspect_handoff. The phrase 'for transfer' implies a use case, but there are no conditions, prerequisites, or alternatives mentioned.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

1 tool updateAug 5, 2026

Changedcompile_handoff10 fields changed

addedInput schema / $defs

Added value: +{
+  "ContractConstraints": {
+    "examples": [
+      {
+        "maxFileBytes": 100000,
+        "requireSha256": true
+      }
+    ],
+    "properties": {
+      "maxFileBytes": {
+        "anyOf": [
+          {
+            "minimum": 1,
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Optional maximum size in bytes for each delivered artifact.",
+        "title": "Maxfilebytes"
+      },
+      "requireSha256": {
+        "default": true,
+        "description": "Require SHA-256 integrity metadata for delivered artifacts.",
+        "title": "Requiresha256",
+        "type": "boolean"
+      }
+    },
+    "title": "ContractConstraints",
+    "type": "object"
+  },
+  "HandoffContext": {
+    "properties": {
+      "assumptions": {
+        "items": {
+          "type": "string"
+        },
+        "title": "Assumptions",
+        "type": "array"
+      },
+      "decisions": {
+        "items": {
+          "type": "string"
+        },
+        "title": "Decisions",
+        "type": "array"
+      },
+      "destinationAgent": {
+        "anyOf": [
+          {
+            "maxLength": 200,
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "title": "Destinationagent"
+      },
+      "objective": {
+        "maxLength": 2000,
+        "minLength": 1,
+        "title": "Objective",
+        "type": "string"
+      },
+      "sourceAgent": {
+        "anyOf": [
+          {
+            "maxLength": 200,
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "title": "Sourceagent"
+      },
+      "status": {
+        "default": "completed",
+        "maxLength": 80,
+        "title": "Status",
+        "type": "string"
+      },
+      "unresolvedIssues": {
+        "items": {
+          "type": "string"
+        },
+        "title": "Unresolvedissues",
+        "type": "array"
+      }
+    },
+    "required": [
+      "objective"
+    ],
+    "title": "HandoffContext",
+    "type": "object"
+  },
+  "OutputRequirement": {
+    "description": "One deliverable expected by the receiving agent.",
+    "examples": [
+      {
+        "acceptedMediaTypes": [
+          "text/markdown"
+        ],
+        "filename": "report.md",
+        "id": "report",
+        "required": true
+      },
+      {
+        "acceptedMediaTypes": [
+          "text/csv"
+        ],
+        "filename": "evidence.csv",
+        "id": "evidence",
+        "required": true,
+        "requiredCsvColumns": [
+          "channel",
+          "score",
+          "evidence"
+        ]
+      },
+      {
+        "acceptedMediaTypes": [
+          "application/json"
+        ],
+        "filename": "summary.json",
+        "id": "summary",
+        "required": true,
+        "requiredJsonKeys": [
+          "recommendation",
+          "confidence"
+        ]
+      }
+    ],
+    "properties": {
+      "acceptedMediaTypes": {
+        "description": "Media types accepted for this deliverable, for example text/markdown, text/csv, or application/json.",
+        "items": {
+          "type": "string"
+        },
+        "minItems": 1,
+        "title": "Acceptedmediatypes",
+        "type": "array"
+      },
+      "description": {
+        "anyOf": [
+          {
+            "maxLength": 500,
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "title": "Description"
+      },
+      "filename": {
+        "anyOf": [
+          {
+            "maxLength": 200,
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Filename required by the receiving agent.",
+        "title": "Filename"
+      },
+      "id": {
+        "description": "Stable requirement identifier. Use the matching source output id when known; use filename only for the delivered filename.",
+        "maxLength": 80,
+        "minLength": 1,
+        "title": "Id",
+        "type": "string"
+      },
+      "required": {
+        "default": true,
+        "description": "Whether this deliverable is mandatory.",
+        "title": "Required",
+        "type": "boolean"
+      },
+      "requiredCsvColumns": {
+        "description": "Use only when acceptedMediaTypes contains text/csv. Leave empty for Markdown, text, JSON, images, and other media types.",
+        "items": {
+          "type": "string"
+        },
+        "title": "Requiredcsvcolumns",
+        "type": "array"
+      },
+      "requiredJsonKeys": {
+        "description": "Use only when acceptedMediaTypes contains application/json. Leave empty for Markdown, text, CSV, images, and other media types.",
+        "items": {
+          "type": "string"
+        },
+        "title": "Requiredjsonkeys",
+        "type": "array"
+      }
+    },
+    "required": [
+      "id",
+      "acceptedMediaTypes"
+    ],
+    "title": "OutputRequirement",
+    "type": "object"
+  },
+  "ReceiverContract": {
+    "description": "Machine-readable input contract declared by the receiving agent.",
+    "properties": {
+      "constraints": {
+        "$ref": "#/$defs/ContractConstraints",
+        "description": "Runtime constraint values. Provide requireSha256 and optionally maxFileBytes; do not copy JSON Schema definitions into this field."
+      },
+      "contractVersion": {
+        "default": "0.1",
+        "title": "Contractversion",
+        "type": "string"
+      },
+      "destinationCapability": {
+        "maxLength": 200,
+        "minLength": 1,
+        "title": "Destinationcapability",
+        "type": "string"
+      },
+      "requiredOutputs": {
+        "items": {
+          "$ref": "#/$defs/OutputRequirement"
+        },
+        "minItems": 1,
+        "title": "Requiredoutputs",
+        "type": "array"
+      }
+    },
+    "required": [
+      "destinationCapability",
+      "requiredOutputs"
+    ],
+    "title": "ReceiverContract",
+    "type": "object"
+  },
+  "SourceOutput": {
+    "description": "One output produced by the source agent.",
+    "properties": {
+      "content": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "title": "Content"
+      },
+      "contentBase64": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "title": "Contentbase64"
+      },
+      "filename": {
+        "maxLength": 200,
+        "minLength": 1,
+        "title": "Filename",
+        "type": "string"
+      },
+      "id": {
+        "maxLength": 80,
+        "minLength": 1,
+        "title": "Id",
+        "type": "string"
+      },
+      "mediaType": {
+        "maxLength": 120,
+        "minLength": 3,
+        "title": "Mediatype",
+        "type": "string"
+      },
+      "role": {
+        "anyOf": [
+          {
+            "maxLength": 80,
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "title": "Role"
+      }
+    },
+    "required": [
+      "id",
+      "filename",
+      "mediaType"
+    ],
+    "title": "SourceOutput",
+    "type": "object"
+  }
+}

addedInput schema / properties / handoff_context / $ref
```
Added value: +"#/$defs/HandoffContext"
```

removedInput schema / properties / handoff_context / anyOf

Removed value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "type": "string"
-  }
-]

removedInput schema / properties / handoff_context / title
```
Removed value: -"Handoff Context"
```
addedInput schema / properties / receiver_contract / $ref
```
Added value: +"#/$defs/ReceiverContract"
```

removedInput schema / properties / receiver_contract / anyOf

Removed value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "type": "string"
-  }
-]

removedInput schema / properties / receiver_contract / title
```
Removed value: -"Receiver Contract"
```
addedInput schema / properties / source_outputs / items / $ref
```
Added value: +"#/$defs/SourceOutput"
```
removedInput schema / properties / source_outputs / items / additionalProperties
```
Removed value: -true
```
removedInput schema / properties / source_outputs / items / type
```
Removed value: -"object"
```

2 tool updatesAug 4, 2026
- Addedcompile_handoff
- Addedinspect_handoff
1 tool updateJul 31, 2026
- First observedprepare_artifact

Frequently Asked Questions

Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.

Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
- GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
- HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
- DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.

The HTTP ownership file has this structure:

{
  "$schema": "https://glama.ai/mcp/schemas/connector.json",
  "claim": "glama_claim_..."
}

Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.

If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.

For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.

Discussions

No comments yet. Be the first to start the discussion!

Related MCP Connectors

agent-handoff-certified-mcp
io.github.CSOAI-ORG
Verifiable agent-to-agent task handoff with signed provenance chain. Initiating agent signs the ...
Agent Orchestration Autonomous Agents
2
Vigil — an outside witness for AI agents
com.vigilnotary
Agent leases, signed receipts, watchdogs, and optional paid source-verification evidence.
261
Venture Foundry QA A
io.github.ventureagent-ai
Preflight QA for AI-agent deliverables with structured verdicts and repair guidance.
Testing & QA Tools Autonomous Agents AI & Machine Learning
51
handoff-mcp-server A
io.github.josephibra
Durable agent-to-agent handoffs and shared scratchpad for multi-agent workflows.
Agent Orchestration Autonomous Agents
32

Related MCP Servers

team-protocol
Autonomous Agents Agent Orchestration CI/CD & DevOps
marshawcoco
F
license
Not graded
quality
B
maintenance
Enables structured role-to-role handoffs and merge gating for multi-agent collaboration. It persists evidence and computes approval gates without invoking LLMs.
Updated 13 days ago (2026-08-23 20:17 UTC)
-
cic-mcp-gateway
RAG Systems Agent Orchestration
CentralInfraCore
F
license
Not graded
quality
B
maintenance
Compiles and routes context from trust-domain sources (session, workdir, knowledge, shared) into unified, trust-tagged context envelopes for agents, without storing any data itself.
Updated 2 months ago (2026-06-26 21:04 UTC)
-
iso20022-evidence-pack-mcp
Finance Legal & Compliance
sebastienrousseau
F
license
A
quality
A
maintenance
Compiles ISO 20022 readiness findings, remediation diffs, and simulated bank responses into sealed, tamper-evident audit evidence packs with Ed25519 signing and verification.
Updated 6 days ago (2026-08-31 02:40 UTC)
11
1
-
Agent Handoff Certified MCP
Autonomous Agents Agent Orchestration Security
CSOAI-ORG
A
license
B
quality
C
maintenance
Verifiable agent-to-agent task handoff with signed provenance chain.
Updated 2 months ago (2026-06-26 05:25 UTC)
5
MIT

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.4/5.0

Disambiguation3/5

compile_handoff and prepare_artifact both produce transferable packages, which could cause confusion about which to use for a given handoff. inspect_handoff is clearly distinct, and tool descriptions help clarify the intended lifecycle stages, but the boundary between compiling and preparing remains somewhat fuzzy.

Naming Consistency4/5

compile_handoff and inspect_handoff follow a consistent verb_handoff pattern, but prepare_artifact breaks the pattern by changing the object and verb style. Overall the naming is readable and predictable despite the one deviation.

Tool Count5/5

Three tools is well-scoped for a focused artifact handoff server, covering compilation, inspection, and preparation without unnecessary bloat. Each tool addresses a distinct lifecycle stage.

Completeness4/5

The set covers the core handoff workflow: compile, inspect, and prepare artifacts for transfer. There is no explicit delivery or acceptance tool, but inspect_handoff returns an acceptance decision, so the lifecycle is reasonably complete with only minor gaps.

Resources

Need Help?