Skip to main content
Glama
macula-io

Macula MCP

by macula-io
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript

mesh_call

Find and invoke procedures advertised on a live P2P mesh, returning the provider's result and duration. Resolve direct-dial advertisements to reach targets without relying on gossip-propagated routes.

Instructions

Invoke a procedure advertised on the mesh (build, test, search, deploy on commons hardware). Macula RPC is procedure-addressed: the target station routes to a peer that advertises it. Returns the peer's result plus duration_ms. Defaults to station-de-frankfurt.macula.io:4433 if host isn't given. If this server's own MACULA_MCP_UCAN is set, its token is attached to every call automatically (harmless against a procedure that isn't UCAN-gated).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
argsNoStructured arguments for the procedure (plain JSON; this server encodes the wire).
hostNoStation to connect through, "host[:port]". Defaults to station-de-frankfurt.macula.io:4433.
realmNo32-byte realm as hex (64 chars), the wire-level tag a procedure is scoped to -- distinct from the realm word inside an MRI string. Omit for the default all-zero realm (protocol-internal, most demo-fleet capabilities). A capability served under its own realm is unreachable without the right one here -- unknown_next_peer with the default realm doesn't necessarily mean the procedure doesn't exist.
directNoResolve the procedure's DHT direct-dial advertisement and call its serving station directly, in one hop, instead of routing through <host>'s own advertise-gossip routes. host is then used only to query the DHT, not to carry the call. Ordinary (non-direct) calls depend on inter-station gossip having already propagated a route from host to the actual server -- on a large or recently-changed mesh that isn't always true yet, and the call can fail (often as temporary_relay_failure) even though the target is live and reachable. direct-dial sidesteps that gap, at the cost of failing outright if the provider only advertised the plain way ("procedure has no direct-dial advertisement"). Prefer this whenever a plain call fails against a target you otherwise know is up. If this server's own MACULA_MCP_UCAN is set, the token still gets attached (via callDirectWithUcan) -- this is how a UCAN-gated capability is actually reached, since today's gated capabilities happen to be advertised direct-dial only (a deployment fact, not a protocol requirement).
procedureYesProcedure name as advertised, e.g. hecate-rag.search_chunks_semantic, with the realm in `realm`. The realm-prefixed form a DHT procedure_advertisement prints (`<64 hex>/<procedure>`) is accepted too and split into procedure + realm for you.
timeout_msNoDeadline in milliseconds for the connect + call.
prove_identityNoSign a {citizen_did, timestamp, procedure} ownership proof with this server's own identity and merge citizen_did + proof into args, for capabilities gated by an ownership proof (hecate_mail.open_mailbox, hecate_graph.learn_link, hecate_citizens.register_presence). The proof is bound to this procedure and to this identity, so it overrides any citizen_did/proof you passed. Presence already registers this identity in hecate-citizens; this is for calling the gated capabilities as that citizen.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.28.7

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and handles it well. It discloses the return shape (result plus duration_ms), the default host, automatic UCAN token attachment, direct-dial behavior and its failure modes, realm scoping semantics, and ownership-proof behavior for gated capabilities.

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

Conciseness5/5

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

The description is dense and efficient: five sentences cover purpose, protocol model, return value, default configuration, and authentication behavior with no redundancy. The core invocation statement is front-loaded before routing and auth details.

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?

Given the complexity of 7 parameters and no output schema, the description plus the detailed input schema covers the invocation path, defaults, routing, authentication, and failure caveats. The return value is described broadly as the peer's result plus duration_ms, which is appropriate for a generic RPC tool even without an output schema.

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?

The input schema already documents all 7 parameters with 100% coverage and rich descriptions, so the baseline is 3. The tool-level prose adds context about the default host and UCAN attachment, but it does not materially expand parameter meaning beyond what the schema already provides.

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?

The description opens with a specific verb plus resource: 'Invoke a procedure advertised on the mesh,' and clarifies the Macula RPC model that distinguishes this tool from sibling tools like mesh_put, mesh_get, or mesh_rooms. The examples (build, test, search, deploy) and the procedure-addressed framing make the tool's purpose unmistakable.

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

Usage Guidelines4/5

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

The description provides clear operational context: procedures are advertised and routed by stations, the default host is given, and the return value is specified. It does not explicitly name alternative tools or state when not to use mesh_call, but the procedure-addressed model gives enough context to select this tool over the data/room-oriented siblings.

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

Install Server

Other Tools