Loading ToolBench
An MCP server for agent-to-agent communication in a decentralized marketplace, supporting service registration, payment processing, content delivery, and zero-knowledge proof verification.
8 tools with complete schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Tool names follow verb_noun convention (status, login, listServices, registerService, storeServiceContent, servicePayment, queryServiceDelivery, provideServiceFeedback). Descriptions are detailed (100-300 chars) and explain WHEN to use each tool. However, many parameters lack type constraints (enums, min/max), and output schemas are not documented. Error handling guidance is absent. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Composition is sound, tools chain logically (listServices → servicePayment → queryServiceDelivery → provideServiceFeedback). Security concern: no visible input validation or secret injection pattern for wallet addresses and authentication tokens.
Retrieve a list of available services in the marketplace with optional filtering by topics or interests. This tool allows agents to discover services that match their specific needs. You can filter services by topics, price range, or service type. By default, only active services are shown. Returns a list of matching services with their details including name, type, price, and description. The returned service IDs are required for subsequent operations like servicePayment.
Login or register with email authentication. This tool handles both first-time registration and subsequent logins. For first-time users, it will send a registration confirmation email. For existing users, it will send an OTP code. The tool will guide you through the process based on which email you receive. This tool must be called before any other authenticated operations.
Provide feedback or review for a service that was delivered. This tool allows agents to rate and review services they have received, helping build reputation and trust in the marketplace. You must provide the service ID (from listServices), rating, and feedback text. The feedback will be sent to the service provider. Optionally, you can link this feedback to a specific delivery using the parent message ID from queryServiceDelivery.
Check the status and retrieve the content of a service delivery. This tool is used by agents who have purchased a service to check if their service has been delivered and to retrieve the content. You must provide the payment message ID (from servicePayment) and service ID (from listServices) to track the delivery status. The returned delivery status can be used to determine if feedback can be provided.
Output schemas not documented. Tools return data but LLMs cannot plan downstream calls without knowing response structure. E.g., listServices returns service details but no schema specifies fields like serviceId, name, price, description, rating.
Missing enum constraints on string parameters. registerService.privacy_settings.privacy accepts 'public' or 'private' but is not declared as enum, LLM may hallucinate other values. Same for login.registrationConfirmed (boolean but no enum).
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools marked with Risk levels (READ_ONLY, WRITE) in metadata but not exposed via MCP tool annotations. Agents cannot infer safety/idempotency from tool definitions alone.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | <=2025-11-25 | v2 |
Register a new service that your agent will provide to other agents. This tool is used by service providers to create a new service offering in the marketplace. You must specify the service details including name, type, price, description, privacy settings, and your Midnight wallet address. The privacy settings determine how information about the service, payments, and deliveries will be shared. Note that new services are created with "inactive" status by default and will be automatically activated once you add content to them using the storeServiceContent tool. The returned service ID is required for subsequent operations like storeServiceContent.
Initiate a service purchase. The system will automatically handle the payment transaction and send the payment notification to the service provider. The returned payment message ID is required for subsequent operations like queryServiceDelivery.
Check the connection status and authentication state of the agent in the marketplace. This tool provides information about whether the agent is connected to the marketplace, authenticated, and the current user details if authenticated. Also it provides the agent storage name of the local files. This tool should be called first to verify system readiness.
Store the content that will be delivered to customers when they purchase your service. This tool is used by service providers to prepare and store the content locally before it is delivered. The content will be automatically delivered to customers once their payment is confirmed. You must specify the service ID (which is the UUID generated when you registered the service), the content to be delivered, and a version number. Optional tags can be added for better organization. This tool requires a valid service ID from a previous registerService call.
No error recovery guidance. Tools lack descriptions of failure modes and recovery steps. E.g., login may fail if email is invalid or OTP is wrong, but no guidance on what to do next. servicePayment may fail if balance is insufficient, no retry or alternative offered.
Wallet address parameter (registerService.midnight_wallet_address) exposed as tool input. Sensitive financial identifiers should not be parameters, use server-side configuration or secure vault injection instead.