Choose files for an agent handoff using filename decisions. No file contents or credentials.
Scored across 3 tools
diagnose_a2a_request is clearly distinct, but prepare_repository_handoff and repository_safety_preflight both operate on repository path metadata with overlapping safety framing, and the latter's terse description makes its boundary with handoff planning unclear. An agent may hesitate over which path-analysis tool to call or in what order.
All names use snake_case, which is consistent, but two follow a verb-first pattern (diagnose_, prepare_) while repository_safety_preflight leads with a noun. The deviation is minor and names remain readable.
Three tools is thin for a server that combines repository handoff planning with A2A protocol diagnosis. Each tool earns its place, but the surface feels borderline under-scoped for the stated purpose.
The domain is handoff planning plus A2A debugging, and the tools only diagnose and plan on caller-supplied entries. There is no way to list repository entries, produce an actual handoff package, or validate the resulting plan, leaving notable gaps.
Diagnose common A2A JSON-RPC SendMessage version and message-shape mistakes. Use when debugging an A2A integration. Send a sanitized request example and selected protocol version, never secrets or headers. Returns fixed field corrections and an authored template. Does not contact an endpoint or certify full conformance.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | Sanitized A2A JSON-RPC body to inspect, not a URL, string or HTTP wrapper. Malformed message fields are allowed for diagnosis. Never include secrets, headers or private content. Entire arguments JSON: at most 16384 ASCII-escaped UTF-8 bytes. | |
| protocolVersion | Yes | Target A2A version from the server's Agent Card, NOT the MCP transport date. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered. The description adds genuinely new behavioral facts: it does not contact an endpoint and does not certify full conformance, which bounds the agent's expectations about what a 'diagnose' call can prove.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, each doing distinct work: purpose, trigger, input constraint, output and limits. Scope and the key safety warning are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter diagnostic tool with no output schema, the description supplies both the expected return (fixed field corrections plus an authored template) and the boundaries (no endpoint contact, no conformance certification). Nothing needed to call or interpret it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters including the enum and the byte limit. The description reinforces the sanitization rule and the source of protocolVersion (Agent Card), but adds little syntax detail beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Diagnose) plus the exact resource (A2A JSON-RPC SendMessage version and message-shape mistakes), which is far more precise than the tool name alone. The siblings (prepare_repository_handoff, repository_safety_preflight) are unrelated domains, so no differentiation is needed, but the scope statement is self-sufficient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use when debugging an A2A integration" gives clear context, and "never secrets or headers" states a hard precondition. It does not name alternative tools or explicitly say when NOT to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
When the user asks which repository files to hand off to another agent or reviewer, call with arguments such as {"entries":[{"path":"src/app.py","kind":"file"}]}. Send permitted relative filenames and kinds only; never file contents, secrets or URLs. Returns exact zero-based include/exclude/skip indexes and reasons for the original entries. This is filename-only planning, not a content security scan or permission to upload.
| Name | Required | Description | Default |
|---|---|---|---|
| entries | Yes |
| Name | Required | Description |
|---|---|---|
| schema | Yes | |
| skipIndexes | Yes | |
| entryDecisions | Yes | |
| excludeIndexes | Yes | |
| includeIndexes | Yes | |
| manifestDigest | Yes | |
| entriesReceived | Yes | |
| contentSecurityVerified | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnly, non-destructive, idempotent), so the bar is lower, yet the description still discloses substantive behavior: it accepts filenames and kinds only, never contents/secrets/URLs, and returns zero-based include/exclude/skip indexes. It closes the loop on what the operation does not do.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, zero waste: trigger first, example payload, constraint, return shape, then scope limitation. Each earns its place and is front-loaded toward the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained in depth — yet it still names the return contract (include/exclude/skip indexes with reasons). Combined with the input constraint and safety framing, an agent has everything needed to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the meaning of 'entries'. It does so by giving a concrete example payload ({"entries":[{"path":"src/app.py","kind":"file"}]}) and stating the constraint: permitted relative filenames and kinds, never contents. That is well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete verb and resource ('which repository files to hand off') and adds a precise scope qualifier: 'filename-only planning.' This distinguishes it from a content scan or security tool, which matters given the sibling repository_safety_preflight.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It supplies an explicit trigger ('When the user asks which repository files to hand off to another agent or reviewer') and explicitly names the alternatives it is not: not a content security scan, not permission to upload. That is textbook when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Zero-effect repository path-metadata preflight. Never send contents, archives, URLs, callbacks, or secrets.
| Name | Required | Description | Default |
|---|---|---|---|
| entries | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully declares zero side effects and explicitly lists data categories never transmitted (contents, archives, URLs, callbacks, secrets), but it does not explain what the tool reads, how it behaves on invalid input, or what it returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler, front-loading the core identity before the safety constraints. It is efficient, though arguably under-specified rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a nested parameter schema, no output schema, and no annotations, the description is too sparse. It omits invocation semantics, return behavior, and sibling differentiation, leaving the agent with insufficient context to call it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. 'Path-metadata' loosely hints at the entries array, but it does not explain the required path+kind object structure, the allowed kind enum values, or the 1024-item limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a resource ('repository path-metadata') and a mode ('preflight'), but the verb is implicit and the overall function remains vague. It partially restates the tool name rather than clearly stating what operation is performed or what a preflight returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the sibling prepare_repository_handoff, nor are prerequisites or exclusions stated. The negative constraints ('Never send...') are safety rules, not usage routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
diagnose_a2a_request3 fields changedInput schema / examplesAdded value: +[
+ {
+ "protocolVersion": "0.3",
+ "request": {
+ "id": 1,
+ "jsonrpc": "2.0",
+ "method": "message/send",
+ "params": {
+ "message": {
+ "messageId": "example-1",
+ "parts": [
+ {
+ "data": {
+ "entries": [
+ {
+ "kind": "file",
+ "path": "src/app.py"
+ }
+ ]
+ },
+ "kind": "data"
+ }
+ ],
+ "role": "user"
+ }
+ }
+ }
+ },
+ {
+ "protocolVersion": "1.0",
+ "request": {
+ "id": 1,
+ "jsonrpc": "2.0",
+ "method": "SendMessage",
+ "params": {
+ "message": {
+ "messageId": "example-1",
+ "parts": [
+ {
+ "data": {
+ "entries": [
+ {
+ "kind": "file",
+ "path": "src/app.py"
+ }
+ ]
+ }
+ }
+ ],
+ "role": "ROLE_USER"
+ }
+ }
+ }
+ }
+]Input schema / properties / protocolVersion / descriptionAdded value: +"Target A2A version from the server's Agent Card, NOT the MCP transport date."Input schema / properties / request / descriptionAdded value: +"Sanitized A2A JSON-RPC body to inspect, not a URL, string or HTTP wrapper. Malformed message fields are allowed for diagnosis. Never include secrets, headers or private content. Entire arguments JSON: at most 16384 ASCII-escaped UTF-8 bytes."diagnose_a2a_requestprepare_repository_handoffrepository_safety_preflightSend API keys and private files to someone else's agent, end-to-end encrypted.
Agent file transfer. No API key to start; price downloads in USDC on Base.
Host files from coding agents; stage on a branch and attach to GitHub PRs.
Securely search and manage workspace context files for AI agents and teams.
Add one secure layer between your agents and this server.
