amtsblatt-mcp

Server Quality Checklist

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

Latest release: v0.22.0
Disambiguation5/5
Each tool serves a distinct purpose: general search, detailed search with full text, procurement-specific search, single publication retrieval, rubric listing, and source status. No two tools overlap in functionality, making agent selection unambiguous.
Naming Consistency5/5
All tools follow a consistent 'gazette_verb_noun' pattern (e.g., gazette_search_publications, gazette_list_rubrics). The naming is predictable and uniform, with clear verb-noun pairs.
Tool Count5/5
With 6 tools, the server is well-scoped for interacting with the Swiss official gazette. Each tool is justified, covering search, retrieval, status, and metadata, without unnecessary extras.
Completeness4/5
The tool set covers all essential operations: searching (list and detailed), single publication retrieval, rubric discovery, and status checks. Minor gaps include lack of bulk retrieval beyond 5 items, but the domain is well-served.
Average 4.4/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 104 commits in the last 12 weeks
- Last stable release on August 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides extensive behavioral details beyond annotations, including: the source is XML, schema varies per subrubric, required fields, best-effort handling of additional_fields, and a secondary check on rubric release that may refuse some IDs. No contradiction with annotations (readOnlyHint, idempotentHint, destructiveHint).
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 well-structured with clear sections (use case, technical details, args, returns) and is front-loaded with the purpose. However, it is somewhat verbose with mixed languages (German and English) and some redundancy (e.g., 'Einzelpublikation inkl. amtlichem Volltext' repeats the use case).
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 tool's complexity (one parameter, output schema present), the description covers usage, edge cases (refused IDs), and return values at a high level. It is complete enough for an agent to use correctly, though it could mention that output structure depends on rubric type.
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 description lists both parameters (id and response_format) with brief additional context (example for id, default value for response_format). The input schema already provides similar descriptions, so the description adds limited extra 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 explicitly states the use case: 'Retrieve the full text of one publication once you have its id from a search.' It clearly identifies the verb (retrieve), resource (full text of publication), and distinguishes from sibling tools like gazette_search_publications which are for searching.
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 that the tool should be used after obtaining an ID from a search ('once you have its id from a search'). However, it does not explicitly state when not to use this tool or provide alternatives among 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?
The description adds significant behavioral context beyond annotations: it explains default filtering to green rubrics, the effect of rubric_class='all', and the important caveat that listing does not imply searchability. Annotations already cover safety, so the description enriches understanding of data semantics.
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 structured but contains a German sentence that may not add value for an agent. The Args section repeats schema info. While it is organized with headings, it could be more concise. Score 3.
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 description covers usage context, parameter behavior, and output overview. Given the presence of an output schema, the brief description of the return value is sufficient. It explains when to use and what to expect, making it contextually complete. Score 4.
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?
The description includes an Args section that mirrors the schema parameters but adds explanatory context, such as the meaning of 'green' vs 'all' and language options. Since the schema already contains descriptions, the description provides moderate added value. Score 4.
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 explicitly states the tool's purpose: to discover available rubrics and their server status, with a clear use case for search troubleshooting. It distinguishes from sibling search tools by positioning this as a prerequisite.
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 usage context: when searches return nothing. It explains the purpose of distinguishing between missing publications and unavailable rubrics. While it doesn't explicitly state when not to use, the sibling tools are search-oriented, making the distinction clear. Score 4 due to lack of explicit negative guidance.
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?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint=false. The description adds significant context: which rubrics are included/excluded, behavior when no rubric is provided, language deduplication and hit count nuance, and the effect of the only_language parameter. No contradiction with annotations.
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 well-structured with a use-case statement, search scope, exclusions, parameter list, and a note on hit count. It is front-loaded. While slightly lengthy, every section provides necessary context for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple parameters, special behavior on rubrics and language), the description is comprehensive. It covers search scope, excluded rubrics, parameter details, return format, and edge cases like language deduplication and hit count. The return value is adequately described even without an explicit output schema shown.
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?
The input schema already includes detailed descriptions for each parameter, so baseline is 3. The tool description adds extra value by explaining the effect of combining rubric with canton, the injection of all rubrics when rubric is omitted, and the hit count and language deduplication behavior, which go 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 official publications in gazette rubrics by keyword, rubric, canton, and date. It positions itself as the general entry point for 'what was officially published about X?' and distinguishes from siblings by mentioning specific use cases and what it does not cover (e.g., personal data rubrics).
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 explicit guidance on when to use the tool ('general entry point'), and clearly states what it does not handle (rubrics with personal data, person name search). It implies alternatives for excluded cases, though it does not name sibling tools directly.
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?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds value by detailing what the tool actually measures (reachability, cache age, scope count) and that it's a non-mutating status check. No contradictions with annotations.
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 includes a <use_case> tag, a German sentence, an English sentence, and an 'Args:'/'Returns:' block. While structured and informative, it is somewhat verbose with language mixing and could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status-check tool with rich annotations and an output schema, the description covers all necessary information: what it checks, when to use it, and what it returns (reachability, latency, cache age, scope metrics). It is fully complete for the tool's complexity.
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?
Despite schema description coverage being 0% per metric, the description explicitly documents the single parameter (response_format) and its valid values ('markdown' or 'json') in the 'Args' section. This compensates well for the lack of schema-level descriptions, adding practical meaning for the agent.
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 checks reachability of amtsblattportal.ch, cache age, and released scope. The <use_case> tag explicitly distinguishes this status-check tool from the sibling search tools, making its purpose highly specific and unambiguous.
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?
The description gives explicit guidance: 'Call this when a search returns nothing and you need to distinguish an empty result from a source that could not be asked.' This tells the agent exactly when to use this tool versus the search siblings, which is textbook usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, etc., but the description adds substantial behavioral context: parallel execution of detail fetches ('Hier laufen die Detailabrufe parallel'), the green gate filtering ('Post-Fetch-Green-Gate'), identical semantics with gazette_search_publications, and that top_n defaults to 3. No contradiction with annotations.
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 well-structured with sections (<use_case>, explanation, when-to-use alternatives, args). It is front-loaded with the primary use case. However, it is somewhat lengthy (multiple paragraphs) and could be more concise without losing important details. Each sentence contributes, but some repetition exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (aggregated search+full text, parallel calls, relationship with multiple siblings, procurement shortcut), the description is remarkably complete. It covers the behavioral model, green gate filtering, identical filters to sibling, when to use alternatives, and the top_n parameter. The output schema exists, so return values are handled.
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 description coverage is 0%, so the description must compensate. It explicitly defines top_n (including range and default) and mentions that other fields are identical to gazette_search_publications. While the schema provides detailed descriptions for all parameters, the description could be more explicit about key parameters like rubric, canton, etc. It adds some value but not full compensation.
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 purpose: to answer a question needing both hit list and full text in one step. It uses specific verbs ('Sucht... UND liefert') and distinguishes from siblings by explaining it's an aggregated tool that saves multiple calls. The differentiation from gazette_search_publications, gazette_get_publication, and gazette_search_procurement is explicit.
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?
The description provides explicit guidance on when to use this tool and when to use alternatives. It lists specific scenarios ('Nur die Trefferliste gewünscht → gazette_search_publications', 'Volltext zu einer bekannten ID → gazette_get_publication', 'Mehr als 5 Volltexte → einzeln holen') and also mentions the procurement shortcut with rubric='OB-<Kanton>'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, destructiveHint, idempotentHint), the description adds critical behavioral context: that results come from simap.ch mirror, which cantons are active/inactive, language duplication behavior, and unique subrubrics. No contradictions with annotations.
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?
Well-structured with sections and bullet points. However, it is somewhat lengthy and repeats language behavior details. Could be more concise, but the structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive: covers data source, canton coverage, language handling, pagination, unique features (subrubrics without simap numbers), comparison with alternative tool, and return format. Given complexity and presence of annotations/output schema, nothing essential is missing.
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?
Despite schema description coverage being 0%, the description includes a detailed Args section that explains each parameter's purpose and constraints (e.g., 'kein CPV-Code', 'Freitext'). Adds context beyond schema property descriptions.
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 purpose: finding public tenders (Submissionen) in the gazette. It specifies procurement-specific entry point and distinguishes from siblings by noting it's for procurement. It also mentions which cantons are covered and points to an alternative for full Swiss coverage.
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?
Excellent guidance: explicitly states when to use this tool (for gazette procurement), when not to use it (full Swiss coverage requires swiss-procurement-mcp). Details limitations (only certain cantons, no CPV codes, duplicate entries due to languages) and gives alternative tool name.
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

Copy to your README.md:

[![amtsblatt-mcp MCP server](https://glama.ai/mcp/servers/malkreide/amtsblatt-mcp/badges/card.svg)](https://glama.ai/mcp/servers/malkreide/amtsblatt-mcp)

Score Badge

Copy to your README.md:

[![amtsblatt-mcp MCP server](https://glama.ai/mcp/servers/malkreide/amtsblatt-mcp/badges/score.svg)](https://glama.ai/mcp/servers/malkreide/amtsblatt-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/malkreide/amtsblatt-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server