Skip to main content
Glama

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.

Related MCP server: TuringWell MCP Server

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

Available Tools

1 tool
a2a_consensus_stepD

A2A 13th-Harmonic Consensus Engine (Requires 402 Payment on Rally 4)

ParametersJSON Schema
NameRequiredDescriptionDefault
tokenNo
point1Yes
point2Yes
paymentNoX-PAYMENT Header value if required
serialNoNo

TDQS

D1.5/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, but it fails to disclose any behavioral traits. It does not state whether the tool is a read or write, what side effects occur, what permissions are needed, or what the response looks like. The only hint is a payment requirement, which is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief but under-specified. It reads as a title, not an explanatory sentence. 'A2A 13th-Harmonic Consensus Engine' is essentially the tool name, and 'Requires 402 Payment on Rally 4' is a cryptic note. No sentence earns its place by clarifying functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters, no annotations, and no output schema, the description is woefully incomplete. It fails to explain the tool's core function, the meaning of required parameters, what the result is, or any side effects. An agent has no way to safely invoke this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 20% (only 'payment' has a description), and the tool's description does not explain any of the five parameters. It adds no meaning beyond the input schema, and with low coverage, it fails to compensate for undocumented parameters like point1, point2, token, and serialNo.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'A2A 13th-Harmonic Consensus Engine' is a noun phrase without an action verb, leaving unclear whether the tool computes, validates, or retrieves consensus. It does not distinguish from siblings (none exist) and provides only a vague hint of what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool vs alternatives. The payment requirement ('Requires 402 Payment on Rally 4') is a prerequisite, not a usage scenario. No exclusions or alternative tools are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev0.1.0
    • First observeda2a_consensus_step

TDQS

D1.8/5.0
Disambiguation2/5

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.

Naming Consistency5/5

A single tool name defines its own pattern. There is no inconsistency. The naming is descriptive of its niche purpose.

Tool Count2/5

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'.

Completeness1/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AGICoffe/a2a-fep-consensus'

If you have feedback or need assistance with the MCP directory API, please join our Discord server