A collection of protocol server implementations including A2A JSON-RPC, JSON-RPC, and Model Context Protocol (MCP) servers for agent-based communication and tool execution.
This server exhibits severe definition quality issues across nearly all tools. Tool names are generic and lack action verbs ('task/process', 'agent/status', 'data/analyze', 'foobar'). Descriptions are uniformly terse (7-39 characters), failing the 10-1024 character guideline and providing no context for LLM decision-making. Input schemas are present but many parameters lack descriptions entirely (task_id, task_type, data in task/process; location in get_weather; query, directory in search_files). No output schemas are documented, leaving LLMs without visibility into return structures. Error handling is minimal, the protocol handler shows basic JSON-RPC error codes but no recovery guidance. The 'foobar' tool is egregiously generic and appears to be placeholder code. Tool composition is poor: 'task/process' conflates task ID, type, and data in a single generic wrapper rather than separate, focused tools. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite the spec supporting them since 2024. Overall, this reads like skeleton code rather than production-ready tooling.
Add two numbers
Get agent status information
Calculate mathematical expressions safely
Analyze provided data
Echo the input parameter back
Add foo and bar parameters
Get system information
Get weather information for a location
Tool names lack action verbs and are generically named. 'task/process', 'agent/status', 'data/analyze', and especially 'foobar' violate naming conventions. LLMs cannot infer intent from these names.
ALL tool descriptions are under 20 characters (7-39 chars observed), violating the 10-1024 character guideline. Descriptions provide no context for when/why to use each tool. Examples: 'Process an agent task' (20 chars), 'Get agent status information' (28 chars), 'Echo the input parameter back' (29 chars).
Many input parameters lack descriptions. In task/process: task_id and task_type have descriptions, but data is marked 'default:{}' with minimal guidance. In search_files: query and directory descriptions are trivial. LLMs cannot infer parameter intent from names alone.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 36 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | - | v1 |
Search for files matching a query
Process an agent task
No output schemas are documented. The source code shows that tools return JSON objects (e.g., task/process returns {task_id, status, result, processed_data, timestamp}), but these structures are not declared in the tool definitions. LLMs lack visibility into return types and cannot reliably extract downstream chain data.
Error handling provides no recovery guidance. The JSON-RPC error handler (a2a-protocol/server.py) returns standard error codes (-32601 'Method not found', -32700 'Parse error', -32603 'Internal error') but does not suggest next steps. LLMs receive no actionable guidance when calls fail.
'foobar' is a placeholder tool name with no semantic meaning. This violates basic tool naming conventions and indicates incomplete tooling.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are declared. All tools are marked Risk: READ_ONLY in the rubric, but this is not explicitly communicated in the tool definitions. The spec supports tool annotations since 2024.
Input parameter types are present but lack depth. For example, 'data' in task/process is typed as 'object' with no nested schema. 'analysis_type' in data/analyze lacks enum constraints (defaulting to 'basic' with no indication of other valid values). Parameters should specify ranges, enums, and formats explicitly.
Tool composition is poor. 'task/process' is a generic wrapper that accepts task_id, task_type, and data, it tries to do too much and delegates specifics to parameters. This violates the principle that each tool should do exactly one thing.