a2a-fep-consensus
# A2A FEP Consensus Node (MCP Server)
An Agent-to-AI (A2A) negotiation and deadlock-resolution Model Context Protocol (MCP) server built on Free Energy Principle (FEP) spatial dynamics and x402 payment protocols.
## Overview
When multiple autonomous LLM agents interact, they often encounter deadlock, semantic stalemate, or hallucination loops. This MCP server exposes deterministic FEP matrix-pruning tools to reduce computational overhead (64x64x1 spatial reduction) and resolve conflicts between competing AI agents using Samurai-Clamp (`候`) syntax verification.
## MCP Capabilities
### Tools
- **`resolve_fep_consensus`**
- **Description:** Resolves semantic deadlocks and conflict states between two or more LLM agents by applying FEP matrix pruning and harmonic phase locking.
- **Input Parameters:**
- `agent_proposals` (array of strings, required): List of competing agent proposals or reasoning outputs.
- `fep_threshold` (number, optional): Free energy reduction sensitivity threshold (default: 0.85).
- **Output:** Pruned consensus state, syntax-locked validation token (`候`), and free energy reduction metrics.
### Prompts
- **`a2a_negotiation_template`**
- A structured prompt template to orchestrate multi-agent negotiations utilizing the `resolve_fep_consensus` tool.
## Integration & Protocol Support
- **Model Context Protocol (MCP):** Fully compliant with MCP v1.0 specification built on Worker edge runtime (`GET /.well-known/mcp.json`).
- **x402 Micro-payments:** Native support for `402 Payment Required` headers enabling autonomous Agent-to-Agent (A2A) transactions (0.01 USDC on Base / Cloudflare Workers).
## Usage & Endpoint
- **Hosted MCP Endpoint:** `https://a2a-fep-consensus.my-agent-api.workers.dev/.well-known/mcp.json`
- **Method:** `POST /v1/consensus`
https://a2a-fep-consensus.my-agent-api.workers.dev
TDQS
Scored across 1 tool
With only one tool, there's no ambiguity between tools. However, the tool's purpose is so specific and obscure that an agent would struggle to determine when to use it, reducing its effective disambiguation to only the model's understanding.
A single tool name defines its own pattern. There is no inconsistency. The naming is descriptive of its niche purpose.
One tool is extremely few for any server and feels too sparse. Even if the tool is complete for its specific action, it's likely to be insufficient for any meaningful workflow with a single step. It earns a 2 due to the severe lack of surrounding 'anatomy'.
The presence of a 'step' implies a larger process that is impossible to execute with only a single, rigid step. There is no 'create', 'update', 'list', or 'get' functionality, which are CRUD operations. The tool's documentation hints at a broader system that is not exposed.