Loading ToolBench
This server provides a protocol tool that can be used to communicate with tx3 files for listing and resolving the transactions inside them.
The tx3-mcp server defines only one tool (ProtocolTool) with severely incomplete definition quality. The tool has a generic, uninformative description that violates best practices. No input schema, parameter descriptions, or output schema are visible in the provided source code. The tool name 'ProtocolTool' is generic and does not follow verb_noun naming conventions (e.g., 'interact_with_protocol', 'query_tx3_registry'). This is a CRITICAL issue: without explicit schema visibility, the tool cannot be properly evaluated by LLMs. The implementation relies on tx3-sdk and cynic for GraphQL interactions, but the tool definition itself lacks the structural clarity required for agent integration.
Describes the transaction '{transaction_name}' from the protocol '{protocol_name}' and shows the required parameters
Resolves the transaction '{transaction_name}' from the protocol '{protocol_name}'
Tool name 'ProtocolTool' is non-standard and violates verb_noun naming convention. Generic nouns like 'Protocol' fail to convey the action the tool performs. LLMs cannot infer intent from this name alone.
No input schema visible in source code. The tool definition shows no parameters, type definitions, or constraints. Cannot verify LLM can understand what inputs the tool accepts.
Tool description 'Tool for protocol interactions with tx3 registry and TRP service' is generic and under 40 chars of substantive detail. Does not explain WHEN to use it, WHAT it returns, or HOW it differs from other tools. Violates 10-1024 char guideline for effective LLM selection.
No output schema documented. LLMs cannot plan downstream tool calls or extract relevant data without knowing the response structure and field types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 11 | - | v1 |
Tool implementation visible in src/tools/protocol.rs but schema definition and parameter documentation not provided in source code excerpt. Cannot verify parameter descriptions, types, or validation rules exist.
No error handling guidance visible. Responses should tell LLMs what to do next on failure (retry, ask user, try alternative tool), but no recovery patterns are documented.
GraphQL integration via cynic suggests complex query/mutation handling, but no documentation of how LLMs should construct or understand GraphQL payloads. This violates the 'chat data model' principle, users say 'query registry', not 'execute GraphQL with field selection'.