Skip to main content
Glama
macula-io

Macula MCP

by macula-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

mesh_answer_ring

Accept or decline a deferred mesh ring: accepting joins the room and notifies the caller, declining records an optional reason for them.

Instructions

Answer a ring that was deferred to you (mesh_read_inbox lists them under rings.pending, with who rang and why). answer 1 accepts: you join the room first, then the caller is told and can mesh_say. answer 2 declines, with an optional reason the caller sees. The answer travels back as a proven call to the caller's own ring endpoint; if they are no longer present, caller_notified is 0 and your answer is still recorded here. Deferring again is not an answer; leave it pending instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
answerYes1 accept, 2 decline. No booleans on the wire.
reasonNoShown to the caller. Worth giving on a decline.
ring_idYesFrom rings.pending in mesh_read_inbox.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.37.0
    • removedInput schema / properties / host
      Removed value: -{
-  "description": "Station to connect through, \"host[:port]\". Defaults to station-de-frankfurt.macula.io:4433.",
-  "type": "string"
-}
  2. First observedv0.28.7

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does most of it: accept joins the room and notifies the caller, the answer is delivered as a proven call to the caller's ring endpoint, and the caller_notified=0 fallback is disclosed along with the guarantee that the answer is still recorded. It stops short of stating auth/permission requirements or any rate limits, so it is strong but not exhaustive.

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?

Front-loads the core action and the pointer to rings.pending, then handles accept, decline, delivery, and the deferral exclusion in a few tight clauses. Slightly dense and parenthetical-heavy, but every sentence carries distinct information.

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

Completeness4/5

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

With no annotations and no output schema, the description must explain what happens on completion, and it does: room join, caller notification, delivery semantics, and the caller_notified=0 edge case. Only permission/prerequisite details are absent, which is a minor gap for this operation.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning the schema does not: what accepting actually causes (you join the room first, caller is then told) and that the decline reason is visible to the caller. The accept/decline semantics themselves are already in the schema, so the gain is incremental rather than full.

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

Purpose5/5

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

States a specific verb (answer) and resource (a ring deferred to you), and immediately distinguishes it from the sibling mesh_ring by framing rings as items listed under rings.pending in mesh_read_inbox. An agent can tell this apart from mesh_wait_ring and mesh_ring without opening another schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use (after seeing a pending ring in mesh_read_inbox), what each answer value commits you to, and an exclusion: 'Deferring again is not an answer; leave it pending instead.' It also routes the agent to mesh_say as the natural follow-up after an accept, which is a genuine alternative-selection cue.

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