mcp-server-zefix

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation4/5
The tools are mostly distinct, but get_company_by_uid and get_company_by_chid both retrieve detailed company info and could be confused. However, the descriptions clearly differentiate them by identifier type, and search/list tools are unambiguous.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (search, get, list) with snake_case throughout. The two get_company_by_* variants are uniformly structured.
Tool Count5/5
Six tools is an appropriate scope for a Swiss company register server, covering search, lookup, and ancillary data without redundancy or bloat.
Completeness4/5
The tool set covers the core functionality of the Zefix register: search, details by identifier, legal forms, publications, and corporate structure. Minor gaps exist (e.g., no direct address lookup or historical searches), but nothing critical for the apparent domain.
Average 4.3/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
- 0 commits in the last 12 weeks
- Last stable release on April 14, 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 declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety. It adds useful context about the CH-ID concept and language options, but does not disclose additional behavioral traits such as error handling, response format, or edge cases, so transparency is adequate but not enhanced 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with the main purpose, then a brief explanatory note about CH-ID, and an Args list. It avoids fluff and is easy to scan, though the Args section partially duplicates schema 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?
With an output schema present and clear annotations, the description provides enough context for correct invocation. It explains the unique identifier and language parameter. The only missing piece is explicit guidance on when to use this tool vs. sibling tools, but that is a minor gap given the overall simplicity.
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 provides only field names and types, but the description's Args section explains both parameters with real-world examples (e.g., CH27030000714) and lists acceptable language values (de, fr, it, en). This significantly compensates for the 0% schema description coverage.
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 states 'Get detailed information about a Swiss company by its CH-ID', which is a specific verb+resource+identifier pattern. It clearly distinguishes from sibling tools like get_company_by_uid by explicitly naming the CH-ID as the lookup key.
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 when a CH-ID is available, and explains that CH-ID is an alternative identifier. However, it does not explicitly mention when to prefer this tool over alternatives (e.g., get_company_by_uid) or any exclusions, so 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?
The description adds useful input format flexibility (accepts various UID formats) and language options, but does not disclose additional behavioral traits like data freshness, rate limits, or output structure. Annotations already indicate read-only safety, so the bar is lower; this scores as adequate but not outstanding.
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 clear purpose, an explanatory note about UID, and an Args section. It is slightly longer than necessary but every sentence serves a purpose, especially given the lack of schema descriptions.
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 lookup tool with an output schema present, the description sufficiently covers purpose, parameters, input formats, and language. It does not explain return values, but the output schema presumably does. It is complete for the tool's complexity, though could mention when to prefer sibling tools.
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 description coverage is 0%, so the description must compensate. It fully explains both parameters: uid (with examples of accepted formats) and language (with allowed values de, fr, it, en). This goes well beyond the schema's simple type definitions.
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 verb 'Get' and resource 'detailed information about a Swiss company by its UID number,' which distinguishes it from siblings like get_company_by_chid and search_companies. The specificity of UID-based lookup makes the purpose unmistakable.
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 when you have a UID, but it does not explicitly mention alternatives or when not to use this tool. It lacks a clear 'use search_companies if you don't have a UID' or similar guidance, so the usage is implied rather than 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 and openWorldHint, so the description's additional context about listing legal forms and language support adds marginal value. It does not contradict annotations and provides enough behavior context for an agent, but does not go beyond what annotations already imply.
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 concise, with a clear main statement, a brief usage note, and an argument spec. Every sentence adds value, and it is well-structured with the purpose front-loaded.
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 list tool with one optional parameter, an output schema, and annotations, the description covers purpose, usage, and parameter semantics completely. It leaves no significant gaps and is fully sufficient for an agent to use it correctly.
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 single parameter 'language' is described with allowed values (de, fr, it, en), adding meaning beyond the schema which only specifies type and default. This fully compensates for the 0% schema description coverage.
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 lists all Swiss legal forms recognized by Zefix, using the specific verb 'list' and naming the resource. This distinguishes it from sibling tools that focus on company searches and details.
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 provides clear context by explaining the tool is useful for understanding legal form IDs in search results or filtering searches by legal form. It does not explicitly mention alternatives or when not to use it, but the context is clear and actionable.
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=true and openWorldHint=true, establishing the safe read-only nature. The description adds valuable behavioral context: wildcard support, the list of returned fields (UID, legal form, registered office), pagination via offset, and language selection. This extends beyond the annotations without contradicting 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 compact (~100 words), opens with the core purpose in the first sentence, and then uses a neatly formatted args list. Every sentence adds operational value, with no filler or redundant statements.
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?
All 7 parameters are described, the search behavior (wildcards, filters) is clear, and the return format is summarized (list with UID, legal form, office). An output schema exists, so deep return-value documentation is unnecessary. The tool's moderate complexity is fully covered by the description.
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?
With 0% schema description coverage, the description fully compensates by explaining every parameter: name with wildcard, canton as two-letter code, active_only filter, language choices, max_results range, offset for pagination, and legal_form_ids as comma-separated values. This turns an otherwise opaque schema into a usable interface.
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 primary function: 'Search Swiss companies in the Zefix register by name.' This is a specific verb (Search) with a well-defined resource (Swiss companies in Zefix register) and method (by name), effectively distinguishing it from sibling tools that focus on exact identifier lookups (get_company_by_uid, get_company_by_chid) or static lists (list_legal_forms).
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 explains how to use the tool (e.g., wildcard syntax, parameter options) but does not explicitly state when to prefer this tool over alternatives. There is no mention of 'use get_company_by_uid for exact matches' or similar exclusions. The use case is implied by the name-based search focus, but not directly articulated as a decision guide.
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 and openWorldHint. The description adds context about the timeline of events (board changes, capital changes, mergers, etc.), but does not disclose rate limits, auth, or pagination. No contradiction.
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?
Description is concise and front-loaded with the main purpose. The args section clearly lists parameters with useful details, every sentence earns its place.
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 2-parameter read-only tool with an output schema, the description is complete. It explains what events are included and provides parameter syntax, making it sufficient for correct invocation.
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 has no property descriptions (0% coverage). The description fully compensates by explaining both parameters: uid format with examples, and language options with valid values.
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 'Get SHAB publications (Swiss Official Gazette) for a company' with a specific verb and resource. It distinguishes from sibling tools like search_companies and get_company_by_uid by focusing on publications timeline.
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 implies usage for retrieving legally significant events for a company, but does not explicitly state when to use this over alternatives or provide exclusions. Context is clear enough.
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 the readOnlyHint annotation, the description reveals key behavioral traits: the output is a table with full addresses, the tool works with either UID type, it fetches up to 50 branches, and performance may be slow due to per-branch API calls. This adds substantial operational context that annotations alone do not convey.
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 well-structured and front-loaded, with the purpose stated in the first sentence. Subsequent sentences add necessary operational details without redundancy, making every sentence meaningful.
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?
The description is complete for a tool with moderate complexity: it covers input semantics, output format (table with addresses), branch limit, and performance characteristics. The presence of an output schema means return-value details are not needed, and the description provides sufficient context for correct invocation.
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?
With zero schema description coverage, the description fully compensates by explaining the uid format with concrete examples and listing the allowed language values (de, fr, it, en). This gives practical guidance beyond the bare schema properties.
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 the corporate structure (head office and branches) of a Swiss company, with specific behavior for head office or branch UIDs. This distinguishes it from sibling tools like get_company_by_uid by focusing on the full organizational hierarchy.
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 implies the use case: when you need the full structure with addresses, not just a single company record. It states that both head office and branch UIDs are accepted, clarifying when it can be used. However, it does not explicitly mention alternatives or when not to use this tool.
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:

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

Score Badge

Copy to your README.md:

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

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/johnphilipp/mcp-server-zefix'

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