zahadun

by medelin

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
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.
Average 3.4/5 across 8 of 8 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

zahadun MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![zahadun MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/medelin/zahadun/badges/card.svg)](https://glama.ai/mcp/servers/medelin/zahadun)

Score Badge

Copy to your README.md:

[![zahadun MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/medelin/zahadun/badges/score.svg)](https://glama.ai/mcp/servers/medelin/zahadun)