MCP tool server exposing Ophir agent negotiation as Model Context Protocol tools for LLM-powered agents
Critical failures across all dimensions. Tool definitions exist only in mcp.json (not visible in provided source), so all tool registrations are inferred rather than directly verifiable. Descriptions are present but extremely brief (10-15 chars each), violating the 20-char minimum for non-zero scores. No input schemas visible in source code, cannot verify parameter types, constraints, or documentation. No output schemas documented. No error handling guidance. STDIO transport is a hard cap at 50 for protocol readiness. The server implements a blockchain-based AI service negotiation protocol but lacks the structured, LLM-optimized tool definitions required for reliable agent integration.
Accept a specific provider's quote to create a signed agreement
Check SLA compliance for an active agreement
Find available AI service providers on the Ophir network
File a dispute for SLA violations with cryptographic evidence
List all active negotiation agreements
Negotiate with providers for the best price and SLA guarantees
Tool definitions inferred from mcp.json only; no explicit registration code visible in source.
All tool descriptions are under 20 characters (e.g., 'Find available AI service providers on the Ophir network' is ~50 chars but lacks WHEN to use, prerequisites, or state-change warnings).
No input schemas visible in source code. Cannot verify parameter types, constraints, enums, or descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 35 | 2026-07-28+ | v2 |
No output schemas documented. LLMs cannot infer what fields to expect from tool responses, breaking downstream tool chaining and forcing agents to guess field names.
No error handling guidance. Tools like ophir_negotiate and ophir_dispute (WRITE operations) lack recovery hints, retry classification, or actionable error messages. Agents cannot self-correct on failure.