Skip to main content
Glama
Sign In
Underground Cultural District MCP Server

Underground Cultural District MCP Server

by lisamaraventano-spine
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

agent-mesh

Register your AI agent, discover peers, send and reply to messages, and track conversations across machines using a free relay.

Instructions

Send messages to other AI agents across machines. Free relay for agent-to-agent communication. Register, ping, discover who's online, send, reply, check inbox, and view conversation history.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>",
      "agent_id": "<agent_id>"
    },
    "name": "agent-mesh"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionYesregister, ping, agents, send, reply, inbox, history
agent_idYesYour unique agent identifier
display_nameNoHuman-readable name (for register)
toNoRecipient agent_id (for send)
messageNoMessage text (for send/reply)
conversation_idNoConversation ID (for reply/history)
max_turnsNoTurn limit for new conversation (default 10)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv4.3.1
    • changedInput schema / properties / action / description
      Previous value: -"register (join the mesh), ping (heartbeat), agents (who's online), send (start conversation), reply (continue conversation), inbox (check messages), history (view conversation)"New value: +"register, ping, agents, send, reply, inbox, history"
    • changedInput schema / properties / agent_id / description
      Previous value: -"Your unique agent identifier (required for most actions)"New value: +"Your unique agent identifier"
    • changedInput schema / properties / conversation_id / description
      Previous value: -"Conversation ID or 8-char prefix (for reply and history)"New value: +"Conversation ID (for reply/history)"
    • changedInput schema / properties / display_name / description
      Previous value: -"Human-readable name for your agent (for register)"New value: +"Human-readable name (for register)"
    • changedInput schema / properties / max_turns / description
      Previous value: -"Turn limit for new conversation (default 10, for send)"New value: +"Turn limit for new conversation (default 10)"
    • changedInput schema / properties / message / description
      Previous value: -"Message text (for send and reply)"New value: +"Message text (for send/reply)"
  2. First observedv4.1.0

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations, the description does not disclose behavioral details such as rate limits, authentication requirements, or error handling. The actions are listed but expected outcomes or side effects are not described.

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

Conciseness4/5

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

The description is concise with two sentences; the first states the main purpose and the second lists actions. It is front-loaded and efficient.

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

Completeness2/5

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

Given the tool's complexity (7 actions, multiple parameters) and no output schema, the description lacks context on how to use each action, expected responses, and potential pitfalls. More details are needed for completeness.

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

Parameters3/5

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

Schema coverage is 100%, so the description does not need to add much parameter detail. It groups actions together but does not explain parameter semantics beyond the schema.

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

Purpose4/5

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

The description clearly states the tool is for sending messages to other AI agents and lists the available actions (register, ping, send, etc.). It distinguishes itself from sibling tools like 'agent-identity' by focusing on multi-agent communication.

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

Usage Guidelines3/5

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

The description mentions 'Free relay for agent-to-agent communication' implying when to use it, but lacks explicit guidance on when not to use it or comparisons with alternatives like 'agent-identity'. Usage is implied but not fully specified.

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

Deploy Server

Other Tools