swiss-food-safety-mcp

Server Quality Checklist

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

Latest release: v1.1.5
Disambiguation5/5
Each tool targets a distinct data source or operation (e.g., animal health stats, antibiotic usage, avian influenza, food control results, pesticide search). There is no overlap in purpose; even the two disease-related tools (blv_get_avian_influenza and blv_search_animal_diseases) differ in scope—wild bird surveillance vs. notifiable diseases. An agent can clearly select the correct tool.
Naming Consistency5/5
All tools follow a consistent 'blv_{verb}_{noun}' pattern in snake_case. Verbs are predictable: 'get' for retrieving specific datasets/stats, 'list' for browsing available datasets, 'search' for querying registries. No mixing of styles or vague verbs.
Tool Count5/5
With 11 tools, the server covers a broad spectrum of Swiss food safety data (animal health, food control, pesticides, nutrition, warnings) without being overwhelming. Each tool addresses a clear need, and the number feels well-scoped for the domain.
Completeness4/5
The tool set provides comprehensive coverage for the BLV's food safety and veterinary data: statistics, surveillance, inspections, warnings, and registry searches. Minor gaps exist (e.g., no tool for foodborne outbreak data or food contact materials), but core workflows like tracking recalls, comparing inspection results, and querying registries are fully supported.
Average 4.1/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 29 commits in the last 12 weeks
- Last stable release on July 31, 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and openWorldHint, which cover safety and idempotency. The description adds minimal behavioral context (returns results and violation rates) but does not contradict annotations. With annotations present, the description's contribution is adequate but not extensive.
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 purpose, and contains zero redundant or unnecessary words. It is highly efficient.
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 presence of an output schema (not shown but noted) and 3 simple parameters fully documented in the schema, the description covers the essential purpose and use case. It does not require additional information about return values or complex behavior, making it 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 3 parameters with descriptions (canton, year, limit), achieving 100% coverage. The tool description does not add any additional meaning beyond what is already in the schema, so a baseline score of 3 is appropriate.
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?
Description clearly states 'food inspection results and violation rates' and provides a use case for comparison across cantons or years. While it is specific, it does not explicitly differentiate from sibling tools beyond the domain (food control vs. animal health, etc.), but the name and context make it clear.
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 includes a 'use case' that suggests when to use the tool (comparing inspection volumes and violation rates), but it does not mention when not to use it or provide explicit alternatives among siblings. This is an implied guidance, not explicit.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows the tool is safe and idempotent. The description adds minimal behavioral context (annual statistics, public data), but does not disclose potential quirks like rate limits or data freshness. With annotations covering safety, a 3 is appropriate.
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 sentences, front-loaded with the main purpose and a practical use case. Every word adds value, and there is no redundancy or fluff.
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 has an output schema and only one optional parameter, the description is mostly complete. It specifies the data source and use case. However, it could briefly mention that data is aggregated or provide a default behavior hint, but for a simple tool this is sufficient.
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 has 100% coverage with a clear description for the 'year' parameter: 'Filter by year (e.g. 2023). None returns all available years.' The description mentions 'year-over-year' but does not add new semantic meaning beyond what the schema provides. Baseline 3 is correct.
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 retrieves annual animal health statistics from BLV, specifying the source (opendata.swiss) and format (CSV/JSON). The name and description together distinguish it from sibling tools like blv_get_antibiotic_usage_vet or blv_get_avian_influenza, which focus on different data.
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 includes a direct use case: 'track year-over-year animal health indicators across Switzerland,' which helps the agent understand when to apply the tool. However, it does not explicitly mention when not to use it or provide alternatives, but the clear context compensates.
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?
Annotations already declare readOnlyHint and idempotentHint, so the description's additional mention of the data source is helpful but does not disclose other behavioral traits like rate limits or pagination. No contradictions.
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 tool's purpose, and wastes no words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With optional parameters, existing output schema, and annotations covering safety, the description provides sufficient context by mentioning the data source and use case. It is adequate for an agent to understand when and how to use the tool.
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 100% for both parameters. The description adds the context of 'livestock species' but does not provide new meaning beyond the schema's own descriptions. Baseline score of 3 applies.
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 provides veterinary antibiotic usage data from the Swiss ISABV monitoring system, with a specific use case for analyzing consumption trends. It implicitly distinguishes from sibling tools that cover other health or food control data.
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 gives a clear use case (antimicrobial-resistance reporting) but does not explicitly state when not to use or suggest alternatives among siblings. The context is clear enough for an agent to select this tool for antibiotic data.
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?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering safety and idempotency. The description adds that data includes geodata and detection dates, which is useful but not extensive. Since annotations already handle behavioral transparency, the description provides adequate but minimal extra context.
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 extremely concise, consisting of two short sentences that front-load the core purpose and then state the use case. Every word adds value, and there is no redundancy or filler.
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 simplicity (2 optional parameters, complete schema descriptions, existing annotations, and an output schema), the description is sufficiently complete. It covers the data source, content, and primary use case without needing to detail output fields.
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?
Input schema coverage is 100% with clear descriptions for both parameters (year and canton). The description reinforces the canton parameter by mentioning 'optionally narrowed to one canton' but adds no new meaning beyond the schema. Baseline 3 is appropriate.
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 retrieves wild bird avian influenza (H5N1/HPAI) surveillance data with geodata, specifying the subject (avian influenza), source (wild birds), and nature (surveillance with geodata). This distinguishes it from siblings like blv_get_animal_health_stats which cover other animal health topics.
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 explicitly provides a use case: 'locate and date wild-bird avian influenza detections, optionally narrowed to one canton.' It does not list when not to use or offer alternatives, but the sibling tools are sufficiently distinct that no further guidance is needed. The granularity of 'optionally narrowed' clarifies when the canton parameter is useful.
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?
Annotations (readOnlyHint, idempotentHint, openWorldHint) already convey key behavioral traits. Description adds context about searching a register but does not introduce new behavioral details beyond what annotations provide.
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 concise sentences, no fluff. Purpose and use case are front-loaded, making it easy to scan.
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 rich annotations, full schema coverage, and presence of an output schema, the description is complete and sufficient for understanding the tool's purpose and usage.
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 coverage is 100% with clear descriptions for all parameters. The description does not add extra meaning beyond the schema, so baseline score is appropriate.
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?
Description clearly states verb 'Search' and specific resource 'Swiss approved pesticide register', and provides a concrete use case. It distinctly differentiates from sibling tools which focus on animal health, food control, etc.
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 use case is clearly stated, and the tool's role is obvious given sibling diversity. However, no explicit when-not-to-use or alternative tools are mentioned, which is a minor gap.
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 openWorldHint. The description adds behavioral detail by naming the specific outputs (slaughter counts and condemnation rates), which helps the agent understand what data to expect without needing to parse the output schema.
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-loading the tool's purpose and immediately following with a concrete use case. Every sentence adds value, no redundant text.
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 low complexity (2 optional parameters) and the presence of an output schema and comprehensive annotations, the description is complete enough for an agent to understand the tool's role and retrieve the expected data. The only minor gap is absence of example values for year or animal_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?
With 100% schema coverage, the schema already documents both parameters (year and animal_type). The description merely echoes these in its use case, adding no extra meaning beyond what the schema provides. A score of 3 is appropriate as the baseline.
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 identifies the tool as providing slaughterhouse meat inspection statistics, specifying 'slaughter counts and condemnation rates by animal type and year.' This distinguishes it from sibling tools like blv_get_animal_health_stats or blv_get_antibiotic_usage_vet, which focus on different data.
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 states the use case as reviewing slaughter counts and condemnation rates, giving clear context for when to use the tool. However, it does not explicitly mention when not to use it or suggest alternative tools for non-matching queries.
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 read-only, idempotent, open-world. Description adds 'live RSS feed' and 'currently active', clarifying that results change over time. No contradictions.
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 sentences, no wasted words. Front-loaded with purpose followed by use case. Ideal structure for an AI agent.
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?
Simple tool with one parameter and output schema; description covers purpose, scope, source, and use case. Could mention update frequency but not critical.
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 coverage is 100%; description adds no additional meaning for the 'limit' parameter beyond its schema description. Baseline score applies.
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?
Clear verb 'get' with specific resource 'public warnings', scope 'Switzerland' and topic 'food recalls'. Distinguishes from siblings which cover animal health, nutrition, etc.
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?
Explicit use case example ('which products have been recalled recently?') and context 'current BLV food recalls and public health warnings'. No negative guidance, but sibling differentiation makes confusion unlikely.
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 declare readOnlyHint, idempotentHint, and openWorldHint. The description adds useful context (data from 1991, InfoSM source) without contradicting annotations. Could add pagination or result details but not required.
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 sentences: the first defines the tool, the second gives a concrete use case. No wasted words, front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's scope (search notifiable diseases since 1991), typical use case, and parameters. Output schema exists to describe return values. Could mention whether results are aggregated or individual cases.
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 coverage is 100% with each parameter described. The description adds no additional parameter meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
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 notifiable animal disease cases in Switzerland since 1991 (InfoSM) and provides a concrete use case with example query. It distinguishes from siblings like blv_get_avian_influenza which is more specific.
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 explicitly indicates the use case (report disease occurrence by canton and year) and gives an example, but does not mention when not to use or compare to alternative 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?
Annotations already declare readOnly, idempotent, and openWorld hints, so the description doesn't need to restate safety. It adds value by describing the output content (metadata, URLs, formats, license) and the relationship to another tool, providing context beyond the annotations.
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 core purpose, and no extraneous text. Every sentence adds value.
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 existence of an output schema (so return values are documented), the description is complete: it covers what the tool does, when to use it, and the key input. No gaps remain.
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 coverage is 100%, and the schema already describes the parameter as 'CKAN dataset name/slug (from blv_list_datasets).' The description reiterates this without adding new semantic detail, so baseline 3 is appropriate.
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 provides 'detailed metadata and resource URLs' for a BLV dataset, using a specific verb (retrieve) and resource (dataset info). It distinguishes itself from sibling tools that focus on specific data types by mentioning it is for general dataset info, and explicitly ties to blv_list_datasets.
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 gives a clear use case: obtain download URLs and formats after finding a dataset via blv_list_datasets. While it doesn't explicitly state when not to use it, the sibling context and the mention of the prerequisite tool provide adequate 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 provide readOnlyHint, idempotentHint, and openWorldHint. The description adds valuable context about the specific dataset (menuCH-Kids) and the intended use case, going beyond the annotations without contradicting them. It does not detail behavioral traits like pagination or data size, but the annotations cover safety and idempotency.
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 highly concise, consisting of two short sentences that front-load the resource name and use case. Every word adds value, with no redundant or filler content.
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 low complexity (2 optional parameters, no required, has output schema), the description fully contextualizes the tool. It specifies the dataset (Swiss national survey), the domain (children's nutrition), and the use case (comparison against recommendations). The presence of an output schema eliminates the need to describe return values.
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 coverage is 100%, with both parameters fully described in the input schema. The description does not add any additional meaning or syntax details beyond what the schema provides, so the baseline score of 3 applies.
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 provides Swiss national children's nutrition survey data (menuCH-Kids) and specifies the use case of examining nutrient intake by age group against recommendations. It is distinct from all sibling tools, which cover animal health, antibiotics, etc., with no overlap.
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 gives a clear use case (examine children's nutrient intake by age group against dietary recommendations) but does not explicitly state when not to use or mention alternatives. However, no sibling tool serves a similar purpose, so the context is sufficient for selection.
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, openWorldHint. Description adds CKAN source and use case but no extra behavioral traits beyond annotations.
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 efficient sentences, no wasted words; front-loaded with purpose and use case.
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?
With output schema present and only two optional parameters, description covers all necessary context for agent usage.
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 coverage is 100% with descriptions for limit and search. Description adds no extra parameter meaning beyond what schema 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?
Description clearly states 'Browse all BLV open datasets' and distinguishes from sibling blv_get_dataset_info by framing use case.
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?
Explicitly says 'discover which datasets exist before drilling into one with blv_get_dataset_info', providing when/why to use and alternative.
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:

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

Score Badge

Copy to your README.md:

[![swiss-food-safety-mcp MCP server](https://glama.ai/mcp/servers/malkreide/swiss-food-safety-mcp/badges/score.svg)](https://glama.ai/mcp/servers/malkreide/swiss-food-safety-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/swiss-food-safety-mcp'

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