fsa-food-safety-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct aspect of food safety regulation: allergen labeling, business classification, HACCP, recall procedures, regulation search, traceability, and database listing. There is no overlap in purpose.
Naming Consistency4/5
Tool names follow a consistent verb_noun pattern (check, classify, audit, list, search, etc.) with snake_case. Minor deviations include 'list_regulations_in_db' (less action-oriented) and British spelling in 'labelling'.
Tool Count5/5
Seven tools provide a well-scoped set for food safety regulation without being excessive or insufficient. Each tool serves a clear regulatory function.
Completeness4/5
The set covers major food safety areas (allergens, HACCP, recall, traceability, regulations search). Missing areas like enforcement or inspection are minor gaps that agents can work around.
Average 3.4/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 16 commits in the last 12 weeks
- No stable releases found
- 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.
This server has been verified by its author.
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?
No annotations are provided, so the description must convey behavioral traits, but it only describes the input and output. It does not state whether the tool is read-only, destructive, or requires authentication (though it mentions an optional API key). The behavior of generating a procedure is implied, but side effects or access needs are not disclosed.
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 structured as a docstring with Args and Returns, making it easily scannable. The first sentence front-loads the purpose. It is relatively concise at 6 lines, though some redundancy exists (e.g., 'Optional query parameter' and 'Optional MEOK API key'). Overall, it earns its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose, parameters, and return format. Given that an output schema exists, it does not need to detail returns, but it still mentions them. However, it lacks context about default behavior when parameters are omitted, prerequisites, or integration with other tools. Completeness is adequate but not thorough.
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 has 0% description coverage, so the description carries the burden. It explains 'query' as optional regulation ref, identifier, or input data, and 'api_key' as optional MEOK API key for Pro+ features. This adds modest meaning beyond the schema's defaults and types, but the explanations are generic and could be more detailed.
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 'Food recall + withdrawal procedure generator', which is a specific verb+resource. It provides a succinct summary of the tool's output, including structured assessment, regulation refs, and recommended actions. However, it could be more explicit about what distinguishes it from siblings like 'allergen_labelling_check' or 'haccp_audit', though the procedural generation is distinct.
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?
The description does not provide guidance on when to use this tool versus siblings or alternatives. It gives parameter descriptions but no context on prerequisites, typical triggers (e.g., a recall event), or conditions under which this tool should be chosen. The absence of usage instructions leaves the agent without decision-making support.
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 exist, so the description carries full burden. It mentions 'Returns: JSON' but does not disclose side effects, required permissions, or whether the tool performs read-only analysis. The behavioral profile is under-specified for a tool that likely queries a database.
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 concise with a clear title and argument list. It front-loads the regulation reference and output summary. However, it could be more structured (e.g., separate sections) without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (traceability with multiple potential inputs), the description is minimally adequate. The existence of an output schema reduces the burden for return values, but the description omits key context like the meaning of 'one up one down' and typical use cases.
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 has no descriptions (0% coverage), but the description adds meaning: 'query' can be regulation ref, identifier, or input data; 'api_key' enables Pro+ features. This clarifies parameter usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool is for 'EU Reg 178/2002 Article 18 traceability' and returns structured assessment, regulation refs, and recommended actions. However, it does not explicitly define 'one up one down' traceability or differentiate from sibling tools, making it somewhat vague.
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 like recall_procedure_template or classify_food_business. The description lacks context on when traceability queries are appropriate or what prerequisites exist.
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 provided, the description must disclose all behavioral traits. It mentions the return type ('JSON with structured assessment, regulation refs, and recommended actions') but does not clarify if the tool modifies any data, requires specific permissions, or has rate limits. This leaves significant ambiguity for the agent.
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 concise at 5 lines, with a clear first-line purpose and organized sections (Args, Returns). Every sentence contributes value, though the Returns line could be more specific.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (classification with two optional params) and the existence of an output schema, the description covers the return format but omits details on classification criteria, error handling, or examples. It is adequate but not comprehensive.
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 schema has 0% description coverage, so the description must add meaning. It explains 'query' as an optional parameter for 'regulation ref, identifier, or input data', and 'api_key' as for 'Pro+ tier features'. This provides useful context that the schema lacks.
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's purpose: 'Determine FSA registration tier (low/medium/high risk)'. The verb 'Determine' and resource 'FSA registration tier' are specific. However, it does not explicitly differentiate from sibling tools like 'allergen_labelling_check' or 'haccp_audit', leaving the agent to infer based on the distinct task.
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. Sibling tools such as 'search_regulation' or 'traceability_one_up_one_down' are not referenced, and there is no discussion of prerequisites or conditions that would make this tool the best choice.
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, and the description does not disclose behavioral traits such as whether the tool is read-only or modifies data. It only mentions the return format, omitting important aspects like authentication requirements 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, stating the purpose upfront and listing parameters in a structured 'Args' section. It avoids unnecessary verbosity, though the 'Returns' line adds minimal value given an existing output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an HACCP audit tool, the description is minimal. It mentions the return includes 'structured assessment, regulation refs, and recommended actions', but lacks details on how the query influences output or fallback behavior when no query is provided.
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%, but the description adds meaning by explaining 'query' as a regulation reference or input data, and 'api_key' as an optional key for Pro+ features. This provides basic context beyond the schema defaults, though more detail on input format would improve.
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 'HACCP 7 principles + 12 steps compliance check', which is a specific verb-resource pair. It distinguishes from sibling tools like 'allergen_labelling_check' and 'classify_food_business' by focusing on HACCP compliance.
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?
The description does not provide any guidance on when to use this tool over alternatives. No context about prerequisites or typical use cases is given, leaving the agent to infer from the tool name alone.
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 provided. Description only states it lists regulations but omits behavioral traits like performance implications, data freshness, or whether it returns limited results. High risk for large databases.
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?
Single sentence, front-loaded with key information, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations. Description gives basic purpose but lacks return format, ordering, or completeness guarantees. Adequate for a trivial list operation but incomplete for robust agent decision-making.
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?
No parameters exist; schema coverage is 100%. Description adds no parameter details because none are needed, meeting the baseline for zero-parameter tools.
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 the tool lists all regulations from a specific local database (EUR-Lex FTS5), with a specific verb and resource, distinguishing it from sibling tools focused on different operations.
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 on when to use this tool versus alternatives like search_regulation. Without context on optimal scenarios, agents may misuse the tool for filtered queries.
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 provided, so description carries full burden. It describes the return format (JSON with assessment, regulation refs, actions) and mentions optional parameters, but does not disclose whether the tool is read-only, destructive, or requires authentication (api_key is optional for Pro+ but not explained further). Lacks disclosure of side effects or limitations.
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: one line stating the purpose, then a formatted args list, and a returns line. Every sentence serves a purpose. Front-loaded with the main function.
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 (as per context signals), the description does not need to detail return values. It mentions the return format adequately. However, it lacks context on when to use this tool versus siblings, and does not explain the overall workflow or prerequisites. For a specific compliance check, it is fairly complete but missing usage guidance.
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?
Schema coverage is 0% (parameters have only titles and defaults), so description must add meaning. It explains that 'query' takes a regulation ref, identifier, or input data, and 'api_key' is for Pro+ tier features. This adds value beyond the bare 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 the tool checks allergen labelling against EU Reg 1169/2011 and Natasha's Law, with a specific verb 'check' and resource 'allergen disclosure'. It distinguishes from sibling tools like search_regulation which likely searches general regulations, and traceability which is about supply chain tracking.
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 usage for allergen labelling compliance but does not explicitly state when to use this tool versus alternatives. No when-not or alternative tool mentions, leaving the agent to infer usage context from the purpose alone.
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?
No annotations provided, so description carries full burden. It transparently describes the return format (snippets with regulation + article + relevance), source (EUR-Lex Cellar), and highlighting. It lacks details on rate limits or potential errors, but overall is adequate.
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?
Structured into Args and Returns sections, each sentence adds value. While not extremely concise, it is well-organized and free of 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 no output schema and no annotations, the description covers purpose, parameters, return format, and source. It lacks error handling details, but overall provides sufficient context for agent use.
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?
Schema coverage is 0%, yet the description adds comprehensive semantics: query with FTS5 syntax, regulation with a list of options, and limit with default value. This fully compensates for the missing schema 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 'Full-text search across 410+ articles of real EU regulation text', which specifies the verb (search) and resource (regulation text), and distinguishes from siblings like 'list_regulations_in_db' and 'classify_food_business'.
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 explains when to use (full-text search), provides optional filters (regulation, limit), and mentions FTS5 syntax support. It does not explicitly state when not to use or compare to siblings, but the context sufficiently implies usage boundaries.
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:

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

Score Badge

Copy to your README.md:

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

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