How do I use zahadun?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@zahadun @bob audit the SEO of example.com" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

zahadun

by medelin

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

zahadun

A self-hosted mesh of full-peer AI agents — Claude Code and OpenCode talking across your machines over A2A, with real mTLS identity and no API keys.

Every machine is an equal peer: it can ask (an MCP bridge inside Claude Code / OpenCode) and answer (an A2A server executing tasks with the local claude CLI, OpenCode, or plain scripts). There is no controller node, no cloud relay, and no per-token billing — the Claude track runs on your existing subscription via claude -p.

you, on machine A                                machine B
┌───────────────────────┐                        ┌───────────────────────┐
│ Claude Code / OpenCode│   A2A JSON-RPC         │ reverse proxy :8443   │
│   │ MCP bridge        │ ──────────────────────▶│   mTLS, CN → identity │
│   ▼                   │   over WireGuard mesh  │   ▼                   │
│ "@bob audit the SEO   │   (NetBird/Tailscale)  │ A2A server :9990      │
│  of example.com"      │                        │   ├─ script           │
│                       │◀── task id, then ──────│   ├─ claude -p        │
│ zahadun_task(id)      │    artifacts           │   └─ opencode         │
└───────────────────────┘                        └───────────────────────┘

Why this exists

Multi-machine agent collaboration is a frequently requested capability. The pieces all exist — A2A↔MCP bridges, WireGuard meshes, workload identity (SPIFFE), agent memory servers — but as separate, mostly cloud- or Kubernetes-shaped projects. zahadun is the whole thing in ~1,500 lines of Python with two dependencies (httpx, mcp), sized for one operator and a handful of machines.

What's different here

Subscription, not API keys. The Claude executor is the CLI in -p mode. If you pay for Claude Code, your mesh costs nothing extra.
One conversation, two machines. The A2A contextId is the Claude session UUID on every machine in a task's path. claude --resume <id> on either end shows that machine's half of the same conversation.
Deterministic @peer addressing. A UserPromptSubmit hook parses mentions before the model sees the prompt. Routing is code, not an LLM decision: unknown peer → hard block with the roster; unreachable peer → the prompt never reaches the local model (you can't mistake a local answer for the peer's).
Conflict-free mesh memory, no database. Shared memory is a git-synced directory of markdown files named <peer>-<timestamp>.md. A peer only ever creates its own files, so replication can't conflict — git pull --rebase never meets a merge.
Real identity, home-lab sized. mTLS everywhere; each machine's cert is signed by your own root CA (an OpenBao PKI mount works well — see docs/CA-RUNBOOK.md). CSR authenticity is attested with an SSH signature (ssh-keygen -Y) from the operator's personal key. Client-only machines get clientAuth-only certs: even a stolen key can't impersonate a server.
Honest cards. A peer's AgentCard lists only skills that work today. A planned skill is a promise the caller can't distinguish from a working one — they just get FAILED.

Related MCP server: claudemesh

Architecture in five decisions

The router is a human. Pure A2A: addressing means choosing a peer. No broadcasts, no capability matching. You say @bob, code delivers to bob.
Tracks are pure end-to-end. A task submitted from Claude Code executes in Claude on the target; OpenCode-to-OpenCode likewise. Mixing tracks would orphan the session history that makes --resume work.
The bridge has no model. The MCP server is an HTTP client plus a file layer. All intelligence lives in the tool that loaded it or on the target peer. It detects its own track from the MCP handshake's clientInfo.
The risky part is code; the convenient part is the model. Delivery and addressing: hook, deterministic. Result pickup, catalogs, memory: MCP tools, model-driven.
Peer input is untrusted. The Claude executor runs headless with no tools by default (permission prompts auto-deny). You grant tools per skill, explicitly, in skills.json. Loops are cut by an X-Zahadun-Trace header; caller identity comes from the client cert's CN via the proxy — never from the request body.

Quick start

See INSTALL.md. The short version, per machine:

# module
python3 -m venv /opt/zahadun-a2a/venv
/opt/zahadun-a2a/venv/bin/pip install zahadun-a2a   # or from a checkout

# client side (every machine): MCP bridge + @peer hook
claude mcp add zahadun --scope user -- /opt/zahadun-a2a/venv/bin/python -m zahadun_a2a.mcp
# + hook in ~/.claude/settings.json, + block in opencode.json  → INSTALL.md

# server side (machines that answer): systemd unit + reverse proxy with mTLS
# examples/ has units and nginx/Apache/Caddy configs

Everything runs as a regular user. No dedicated system account, no root services — the Claude executor needs the user's ~/.claude anyway.

MCP tools exposed to your agent

tool	purpose
`zahadun_peers()`	who is in the mesh, what they can do (live AgentCards)
`zahadun_ask(peer, task, …)`	delegate; returns a task id
`zahadun_task(id)`	poll result / status
`zahadun_models()`	live model catalog of the local OpenCode engine
`zahadun_memory_search/read/write/topics`	shared mesh memory

Status

Working: the full client+server loop, three executors (script / claude -p --session-id / OpenCode prompt_async with a model-fallback ladder), task persistence across restarts, audit log, loop detection.

Not yet: SSE streaming (cards honestly say streaming: false), input-required pauses (skills marked as needing human confirmation are refused, not hung), per-caller rate limits.

Security model

Read SECURITY.md before exposing anything. Summary: designed for a single operator's machines on a private WireGuard mesh; peers are semi-trusted (authenticated, but their task content is not); it is not a multi-tenant system and was never designed as one.

A note on language

The project was built for a Polish-speaking mesh: code comments, error messages and some config keys (drabina = model ladder, wykonawca = executor, potwierdzenie_czlowieka = human confirmation) are Polish. The docs you're reading, the wire protocol (A2A v1.0) and the MCP tool names are English. Translating internals is on the table if anyone actually needs it — open an issue.

License

Apache-2.0.

Available Tools

8 tools

zahadun_askA

Zleca zadanie peerowi w siatce. Zwraca identyfikator zadania - wynik odbierz przez zahadun_task. temat to contextId (UUID) wspolny dla sesji na obu maszynach; pominiety - zostanie wygenerowany.

ParametersJSON Schema

Name	Required	Description	Default
`peer`	Yes
`model`	No
`temat`	No
`zadanie`	Yes
`narzedzie`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations provided, the description must carry the full burden. It discloses that the tool returns a task identifier and that the result is asynchronously retrieved via zahadun_task. It also explains the `temat` parameter's role as a shared contextId. This adds valuable behavioral context beyond the schema, though it omits error behavior or side effects.

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 two sentences long, front-loads the primary purpose, and uses no filler words. It efficiently communicates the core action, return value, and a key parameter detail.

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?

The tool has 5 parameters and no annotations, yet the description only covers one parameter and the basic flow. It does not mention prerequisites (e.g., knowing a peer) or provide context for other parameters. While an output schema exists and may cover return values, the overall context is incomplete for a tool of this complexity.

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

Parameters2/5

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

The schema has 5 parameters with 0% description coverage. The description only explains `temat`, providing no additional meaning for peer, model, zadanie, or narzedzie. Given the low schema coverage, the description should compensate but fails to do so for most parameters.

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 clearly states the tool's function: 'Zleca zadanie peerowi w siatce' (assigns a task to a peer in the grid). It also distinguishes itself from sibling tools by explaining that the result is obtained via zahadun_task, making this a task-creation tool rather than a retrieval tool.

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 workflow guidance by stating 'wynik odbierz przez zahadun_task' (retrieve result via zahadun_task), indicating when to use this tool and what to do next. However, it does not explicitly discuss alternatives or when not to use this tool, so it falls short of a perfect score.

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

zahadun_memory_readC

Odczyt tematu (po contextId) albo wpisu wspolnego (po slugu).

ParametersJSON Schema

Name	Required	Description	Default
`tor`	No
`temat`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description carries the full burden for behavioral disclosure. It mentions two modes (topic vs. common entry) but does not explain error handling, return behavior, side effects, or permission requirements. It leaves the distinction between modes under-specified regarding how parameters select them.

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 a single, front-loaded sentence with no redundant information. It communicates the core purpose efficiently, making every word earn its place.

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?

For a tool with 2 parameters and an output schema, the description is too terse. It does not clarify the two modes in terms of parameters, when to use this vs. memory_search, or what the output resembles (though an output schema exists, the description still leaves ambiguity). The description is minimally viable but lacks essential context for a correct invocation.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It mentions contextId and slug but does not explicitly map them to the 'temat' and 'tor' parameters. The required 'temat' parameter makes the slug-only path unclear. This adds some conceptual meaning but fails to fully explain how to use the parameters.

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 reads either a topic by contextId or a common entry by slug, using the verb 'Odczyt' (read) and naming the resources. It distinguishes itself from memory_write and memory_search by nature, though it does not explicitly name alternatives. However, the mapping of parameters to contextId/slug is left ambiguous, preventing a perfect score.

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 provided on when to use this tool versus the sibling tools like memory_search or memory_write. There is no mention of prerequisites, scenarios, or exclusions. The description only states what it does, not when to choose it.

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

zahadun_memory_searchA

Przeszukuje pamiec mesh po tresci (ripgrep po katalogu toru).

ParametersJSON Schema

Name	Required	Description	Default
`tor`	No
`fraza`	Yes
`temat`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

The description mentions ripgrep over a directory, giving some implementation insight and indicating a read-only search operation. However, with no annotations, it does not disclose output behavior, error cases, or whether it modifies anything, so it only partially covers behavioral transparency.

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 a single, front-loaded sentence with no redundant words. It efficiently conveys the core functionality and method, earning its place.

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?

The tool has 3 parameters with no schema descriptions, and the description only partially explains them. It also does not clarify how this search differs from memory_read or what 'temat' does, leaving significant gaps. The presence of an output schema does not offset the missing parameter semantics and usage guidance.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It hints that 'tor' relates to a directory ('katalog toru') and that 'fraza' relates to content ('tresci'), but it does not explain the parameters explicitly or clarify the role of 'temat'. This adds minimal value beyond the schema.

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 clearly states it searches memory mesh by content, using a specific method (ripgrep over directory). This distinguishes it from sibling tools like memory_read (read specific memory) and memory_topics (list topics), making its purpose unambiguous.

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 implies use for finding memories by content but does not explicitly state when to use it versus alternatives like memory_read or memory_topics. There is no exclusion or condition given, so usage guidance is only implied.

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

zahadun_memory_topicsC

Lista tematow i wpisow wspolnych w pamieci mesh.

ParametersJSON Schema

Name	Required	Description	Default
`tor`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It only implies a read-only list operation but does not explain the 'tor' parameter, what 'common entries' means, or any requirements or side effects. This is insufficient for a tool with zero annotation support.

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

Conciseness3/5

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

The description is a single short sentence, making it concise and front-loaded. However, it is under-specified, omitting essential details about parameters and behavior, which reduces its overall value.

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?

For a simple list tool with an output schema, the description is not complete enough. It does not explain the 'tor' parameter or clarify the meaning of 'wspolnych,' and the absence of annotations leaves critical gaps for correct invocation.

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?

The only parameter 'tor' is completely undocumented, and the description does not mention it. With 0% schema description coverage, the description must compensate, but it fails to add any meaning to the parameter.

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 a list operation on topics and entries in mesh memory ('Lista tematow i wpisow wspolnych w pamieci mesh'). It uses a specific verb and resource, and it is distinguishable from siblings like memory_search and memory_read, though the term 'wspolnych' (common/shared) is slightly ambiguous.

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 provided about when to use this tool versus alternatives such as zahadun_memory_search or zahadun_memory_read. The description lacks any context, prerequisites, or exclusions.

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

zahadun_memory_writeA

Zapis do pamieci mesh. temat to contextId biezacego tematu albo slug wiedzy ponad tematami (wtedy ustaw wspolne=true). Tworzy nowy plik - nigdy nie nadpisuje cudzych wpisow.

ParametersJSON Schema

Name	Required	Description	Default
`tor`	No
`tagi`	No
`temat`	Yes
`tresc`	Yes
`tytul`	No
`wspolne`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses a key behavior: creates a new file and never overwrites others' entries. However, it does not mention failure modes, permissions, or side effects beyond file creation, leaving gaps in transparency.

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 two concise sentences, front-loading the main action and adding only relevant details about the parameter and non-overwriting behavior. Every word earns its place with no redundancy.

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?

The tool has 6 parameters, no schema descriptions, and no annotations; the description covers only one parameter meaningfully and omits usage guidance vs siblings. Though an output schema exists, it does not mitigate the lack of parameter explanations and contextual details.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It explains `temat` and references `wspolne`, but leaves `tor`, `tagi`, `tresc`, and `tytul` completely unexplained. With 6 parameters and 2 required, this is insufficient for effective usage.

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 clearly states the tool writes to mesh memory, creates a new file, and never overwrites others' entries. This distinguishes it from sibling tools like memory_read and memory_search, and the specific verb 'write' combined with the resource makes the purpose unambiguous.

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 provides useful parameter-level guidance for `temat` (contextId vs shared slug with wspolne=true), but it does not explicitly state when to use this tool over alternatives like memory_search or memory_read. Usage is implied rather than directly contrasted with siblings.

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

zahadun_modelsA

Zywy katalog modeli toru opencode wraz z cenami (z lokalnego serwera OpenCode). Model spoza katalogu jest bledem, nigdy cichym podstawieniem.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/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 burden. It discloses that the catalog is live, sourced from a local OpenCode server, and that out-of-catalog models are errors rather than silently substituted—important behavioral context beyond a simple listing.

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 two sentences, front-loaded with the main purpose, and every sentence adds value. No filler or redundancy.

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?

For a simple no-parameter tool with an output schema, the description covers the core purpose and key behavioral guarantee. It is sufficiently complete for an agent to understand what the tool does and its error policy, though it could mention return format if the output schema were absent.

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?

There are zero parameters, so no parameter details are needed. The baseline for zero-parameter tools is 4, and the description adds nothing that conflicts with or duplicates schema info.

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 identifies the tool as providing a live catalog of opencode models with prices, which is specific and distinguishes it from sibling tools focused on peers, tasks, and memory. However, it lacks an explicit verb like 'get' or 'list', relying on the noun 'catalog' to imply retrieval.

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 explicit guidance is given on when to use this tool versus alternatives. The behavioral note about models outside the catalog being errors is useful but does not address usage context or trade-offs compared to sibling tools.

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

zahadun_peersC

Kto jest w siatce zahadun i co umie (z AgentCards).

ParametersJSON Schema

Name	Required	Description	Default
`odswiez_karty`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the burden. It mentions the source ('AgentCards') but does not disclose behavioral traits such as whether results are cached, if there are rate limits, or how the refresh parameter affects output.

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 a single concise sentence with no wasted words. It front-loads the core purpose effectively.

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 simplicity (one optional parameter) and existing output schema, the description explains the basic purpose but omits critical context such as parameter behavior and usage scenarios, making it insufficient for confident invocation.

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?

The single parameter 'odswiez_karty' is completely undocumented in the description. With 0% schema coverage and no description-level explanation, the agent receives no meaningful information about what the parameter does.

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 states the tool tells who is in the zahadun network and what they can do, which clearly identifies its purpose and differentiates it from siblings like ask or task. However, it lacks a specific verb like 'list' or 'show', making it slightly less explicit.

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 provided on when to use this tool versus alternatives, nor any prerequisites or use cases. The description is purely descriptive with no contextual instruction.

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

zahadun_taskA

Odbior wyniku lub statusu zadania. id w formacie 'peer:taskId' (tak jak zwrocil zahadun_ask).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses that the tool returns either a result or a status, implying it can be used before task completion, but it does not detail response shape, error handling, or whether it blocks.

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?

Two short clauses; every word contributes. It avoids redundancy and front-loads the core purpose.

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?

The tool is low complexity (one parameter, output schema present), and the description covers purpose, id formatting, and its link to zahadun_ask. It lacks explicit usage timing beyond that, but with an output schema available, return values need not be described.

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

Parameters5/5

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

The schema only defines `id` as a required string; the description adds crucial format semantics ('peer:taskId') and provenance, fully compensating for the 0% schema coverage for this single parameter.

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 uses a specific verb ('Odbior' = retrieval) and resource ('wyniku lub statusu zadania' = result/status of a task), clearly distinguishing it from siblings like zahadun_ask (submission) and zahadun_peers (peer listing).

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?

It explicitly states that the `id` is in 'peer:taskId' format 'as returned by zahadun_ask', which ties its usage to a specific workflow. However, it does not explicitly state when to prefer this over alternatives or mention polling/waiting behavior.

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.

8 tool updatesv0.2.0Aug 8, 2026
- First observedzahadun_ask
- First observedzahadun_memory_read
- First observedzahadun_memory_search
- First observedzahadun_memory_topics
- First observedzahadun_memory_write
- First observedzahadun_models
- First observedzahadun_peers
- First observedzahadun_task

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Scored 2026-08-08 19:45 across 8 tools

Disambiguation5/5

Each tool targets a distinct function: peer discovery, task submission, task status retrieval, model catalog, memory search, read, write, and topic listing. There is no overlap between task and memory operations, and request/response pair (ask/task) is clearly separated.

Naming Consistency4/5

All tools share the 'zahadun_' prefix, and the memory tools follow a 'memory_<action>' pattern. However, some names are bare nouns (peers, task, models) while others are verbs (ask) or compound nouns (memory_topics), creating minor inconsistency in naming style.

Tool Count5/5

With 8 tools, the set is well-scoped for the server's purpose of managing an agent mesh network, task delegation, and shared memory. Each tool serves a clear role without redundancy or bloat.

Completeness4/5

Core workflows are covered: task lifecycle (submit, retrieve status/result), peer discovery, and memory operations (write, read, search, list). Minor gaps exist such as no task cancellation or listing of all tasks, but these are not essential for the primary use case.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

SentinelX MCPOAuth
app.sentinelx
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Shell Access OS Automation
27
Route6 — Agent Network Identity
me.route6
Gives AI agents a public IPv6 identity, hostname, port forwarding, web fetch, team mesh. Free tier.
Networking & Infrastructure Agent Orchestration
2
aXOAuthDeprecated
io.github.ax-platform
Agent-native collaboration network: orchestrate a team of long-running agents from any MCP client.
Knowledge & Memory Autonomous Agents Agent Orchestration
36
Agent Commons A
dev.alexlabs
End-to-end encrypted messaging and work coordination for autonomous AI agents.
Autonomous Agents Communication
341

Related MCP Servers

slm-mesh
Agent Orchestration Autonomous Agents
qualixar
A
license
Not graded
quality
C
maintenance
Enables peer-to-peer communication, discovery, shared state, and file coordination between AI coding agents across machines and sessions.
Updated 4 months ago (2026-05-25 07:44 UTC)
5
19
Elastic 2.0
claudemesh
Autonomous Agents Agent Orchestration
alezmad
A
license
Not graded
quality
A
maintenance
Enables Claude Code agents to communicate and share context across sessions via a peer-to-peer mesh, allowing them to ask for help from other agents without human interruption.
Updated 2 days ago (2026-09-08 22:27 UTC)
9
MIT
Maestro MCP
Shell Access Command Line Agent Orchestration
rmstxrx
A
license
Not graded
quality
C
maintenance
Enables AI agents to orchestrate a heterogeneous machine fleet via SSH, with unified command execution, file transfer, and dispatch of coding agents across platforms.
Updated 2 months ago (2026-07-12 21:43 UTC)
1
Apache 2.0
Codex SSH Terminal MCP
Shell Access Command Line
NullPointerChef
A
license
B
quality
C
maintenance
Agent-native SSH control plane with a local Web Terminal, human-in-the-loop secret input, keychain-backed profiles, and user-confirmed uploads for Codex, Claude Code, and MCP-compatible coding agents.
Updated 2 months ago (2026-07-22 17:03 UTC)
18
1
Apache 2.0