swiss-ip-mcp

Server Quality Checklist

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

Latest release: v1.1.6
Disambiguation5/5
Each tool targets a distinct resource and action, e.g., 'swiss_ip_get_patent' vs 'swiss_ip_search_patents' vs 'swiss_ip_search_patents_by_applicant'. Overlaps are minimal and clarified by descriptions.
Naming Consistency5/5
All tools follow 'swiss_ip_<verb>_<resource>' with snake_case, e.g., 'search_patents', 'get_trademark', 'search_trademarks_by_owner'. The pattern is predictable and uniform.
Tool Count5/5
11 tools cover patents, trademarks, SPC, recent filings, and quota. This is well-scoped for a domain-specific IP data server; neither too few nor too many.
Completeness5/5
The surface covers CRUD-like querying (search and get) for all major IP types (patents, trademarks, SPC), plus quota monitoring and recent filings. No obvious gaps for a read-only API.
Average 4/5 across 11 of 11 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 43 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description's additional note about date_to being exclusive adds value but is not major. The description does not contradict 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 (6 lines), front-loads the purpose, and uses structured tags for emphasis. It avoids redundancy but could be slightly more streamlined.
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 multiple siblings and pagination complexity, the description covers the core behavior and return structure but lacks guidance on pagination flow or when to use page_token. An output schema exists (not shown) but isn't referenced.
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's top-level parameter lacks description (coverage 0%), but the inner properties are well-described in the schema. The description repeats these and adds the exclusive note for date_to, offering slight additional value beyond the schema.
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 searches Swiss IP entries within a date range, listing supported types (trademark, patent, etc.). However, it does not explicitly differentiate from sibling tools that target specific IP types, which would clarify when to use this general search vs. specialized ones.
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 <use_case> tag suggests Trendanalyse, providing implied usage context. The <important_notes> give key behaviors (date_to exclusive). However, no explicit guidance on when not to use the tool or alternatives like swiss_ip_search_patents for specific types.
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. The description adds the context of searching official publications but does not significantly supplement the behavioral profile 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 reasonably concise, with a clear use case and parameter list. The structure is adequate, though the inclusion of a <use_case> tag is somewhat unconventional.
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 outlines the return fields and the tool's purpose. Given the output schema exists, further detail on return structure is unnecessary. However, pagination behavior via page_token could be clarified.
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 high description coverage (100% with descriptions for all parameters), so baseline is 3. The tool description lists three of four parameters (missing sort_descending) and adds no new semantic meaning beyond the schema.
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 it searches Swiss patent publications, with a specific use case for prior art searches. However, it does not explicitly differentiate from siblings like swiss_ip_search_patents, which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a use case ('Stand-der-Technik-Recherche und Innovationsmonitoring') but lacks explicit guidance on when not to use this tool versus alternatives, or prerequisites.
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 the tool as read-only, idempotent, and non-destructive. The description adds behavioral context like pagination (page_token, next_page_token), result order (sort_descending), and wildcard support. This enriches the agent's understanding 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 well-structured with a use_case tag, parameter list, and return description. It is concise and front-loaded, though the mix of German and English and minor formatting (e.g., 'Enthält:' capitalization) slightly reduce clarity.
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 read-only search tool with an output schema, the description adequately explains inputs and return structure (source, total, count, results, next_page_token). It could be more complete by detailing the meaning of 'source' or 'total,' but overall it covers essential operational context.
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?
Despite a stated 0% schema description coverage, the description comprehensively explains all parameters: query (with examples like 'Zürich*', 'apple'), page_size (range 1-50, default 10), page_token (pagination token), and sort_descending (default True). It provides clear semantics and usage details, fully compensating for the schema gap.
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 searches the Swiss trademark register via free text, using phrases like 'Durchsucht das Schweizer Markenregister nach Freitext' and 'Findet Marken nach Name, Markenbegriff oder Stichwort.' It is specific and uses a strong verb+resource structure, but does not explicitly differentiate from sibling tools like class or owner searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context with a <use_case> tag ('Markenrecherche / Brand-Monitoring per Name, Wort oder Stichwort') and mentions wildcard support. However, it does not specify when not to use this tool or suggest alternatives, such as searching by class or owner, which are available as 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating safety and idempotency. The description adds behavioral details: it performs an exact lookup, returns a full dataset including IPC codes, applicant, inventor, and status. 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?
The description is concise, using XML-like tags to structure key information (use_case, important_notes). It is front-loaded with the purpose and important note. However, the 'Args:' section repeats schema details, introducing minor redundancy. Overall efficient and well-structured.
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 simplicity (single parameter, exact lookup) and the presence of an output schema (not shown but indicated), the description adequately covers the tool's behavior and return content. It includes constraining notes (exact match) and lists key return fields. No gaps for this complexity level.
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 repeats parameter information already present in the schema (patent_number with example). It adds no significant new meaning beyond what the schema's description field provides. With schema description coverage at 0% (though the schema itself contains a description), the description offers marginal added value. 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.
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 a specific Swiss patent by number ('Ruft ein bestimmtes Schweizer Patent anhand seiner Nummer ab'). The use_case tag reinforces this as a detail retrieval. It distinguishes itself from sibling search tools by emphasizing 'exakter Lookup; kein Fuzzy-Match', making it clear when to use this tool versus the search alternatives.
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 important_notes tag explicitly states 'Exakter Lookup; kein Fuzzy-Match', indicating this tool is for exact patent number lookups and not for fuzzy searches. While it doesn't name alternative tools, the sibling context provides search tools for broader queries. The guidance is clear but could be stronger by explicitly mentioning when to use search tools instead.
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, destructiveHint=false, idempotentHint=true, openWorldHint=true. Description adds that lookup is exact and returns match_type='none' on failure, which is mild additional context. 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?
Description is concise (5 sentences) with structured sections (use_case, important_notes). No fluff, front-loaded with key action.
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 single parameter, good annotations, and existing output schema, the description covers the retrieval behavior, return overview, and exact matching. Complete for a simple lookup 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 already provides a description for trademark_number with examples. Description repeats the parameter with an example, adding marginal value. With 0% schema_description_coverage metric, the parameter is actually documented in schema, so baseline is 3.
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 a specific Swiss trademark by application/registration number. It distinguishes from sibling tools which are search-oriented or for patents.
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?
Provides explicit use case ('Detail-Abruf einer Marke per Anmelde-/Registernummer') and notes exact lookup behavior with match_type='none' for unknown numbers. However, it does not explicitly exclude alternative 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 readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by outlining the return structure (source, total, count, results, next_page_token) and explaining that SPC extend patent protection, which is behaviorally relevant.
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 (3 sentences plus Args/Returns) and front-loaded with the main purpose. Use case tag is efficient. No unnecessary details.
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, the description need not detail return values but does so helpfully. It covers the required query parameter and pagination. For a search tool, it is sufficiently complete.
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% per context, so the description must compensate. It lists the query parameter with examples ('Novartis', 'ibuprofen*'), but for page_size and page_token, it only provides brief translations without additional semantics beyond the schema's constraints. Partial 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 it searches Swiss Supplementary Protection Certificates (ESZ/SPC) with a specific verb 'Durchsucht' and a dedicated use case tag. It distinguishes from sibling tools focused on patents and trademarks by targeting SPC, a distinct IP type.
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 specifies the domain (pharma/plant protection) and the IP type (ESZ/SPC), guiding when to use it. However, it does not explicitly mention when not to use or compare to siblings like patent searches.
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 indicate readOnlyHint=true, idempotentHint=true, making it a safe search. The description adds return format details (source, total, count, results, next_page_token) and mentions pagination, but does not cover any additional behavioral traits like rate limits or required permissions.
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 front-loaded with the main action and use case, followed by a concise parameter list. It avoids unnecessary repetition, though the args list somewhat duplicates schema content.
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 output schema exists, the description need not detail return values, but it still mentions the return format. It covers pagination, the required nice_class, and optional filters. Missing example values or error handling, but overall complete for a search tool.
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?
Though schema descriptions exist for nice_class and query, page_size and page_token lack descriptions. The description lists all parameters and explains nice_class range, query as optional text filter, page_size results per page, and page_token for pagination, adding 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 states 'Durchsucht Schweizer Marken nach Nizza-Klassifikation' (searches Swiss trademarks by Nice classification) and provides a specific use case 'Branchenanalyse: Marken einer Nizza-Klasse (1-45) finden.' This clearly differentiates from siblings like swiss_ip_search_trademarks and swiss_ip_search_trademarks_by_owner.
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 tag indicates when to use (industry analysis by class). While it does not explicitly state when not to use, the scope is clear and sibling tools are listed, providing alternatives.
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 destructiveHint=false. The description adds behavioral details: pagination via page_size/page_token and return structure (source, total, count, results, next_page_token). 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 clear main sentence, use_case tag, and args/returns sections. It is concise without wasted words, though could be slightly shorter.
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 simplicity (search with pagination) and presence of annotations and output schema, the description covers purpose, input, and output adequately. Lacks error handling or rate limit info but is sufficient for correct invocation.
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% per context, but the schema actually has descriptions for owner_name and page_size. The description lists args with examples (e.g., 'Nestlé*') but adds minimal new meaning beyond the schema. Adequate but not exceptional.
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 ('Durchsucht' = searches), resource ('Schweizer Marken'), and filter ('nach Inhaber / Anmelder'). It distinguishes from siblings like swiss_ip_search_trademarks_by_class by specifying the owner filter.
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 specific use cases: Portfolio-Analyse and IP-Monitoring. However, it does not mention when not to use this tool or alternatives among siblings, slightly reducing 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 declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by listing the return fields (title, applicant, IPC classification, dates, legal status) and parameter details, which go beyond the annotations without contradiction.
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 reasonably concise, with a clear structure: purpose sentence, use case tag, return summary, and labeled Args section. The use of formatting (use_case tag) aids readability, though the Args block is somewhat verbose.
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 (single nested param with four sub-params) and the existence of an output schema, the description covers the use case, pagination (page_token), and expected return fields. It is sufficiently complete for an agent to understand and invoke the tool 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?
Although schema description coverage is 0% (top-level 'params' lacks description), the description explicitly lists each parameter, provides examples for 'query', and explains defaults like 'sort_descending: Neueste zuerst'. This adds meaningful guidance beyond the schema's structure.
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 directly states 'Durchsucht das Schweizer Patentregister nach Freitext' (Searches the Swiss patent register by free text), and the annotation title confirms 'Schweizer Patente suchen'. Among sibling tools specializing in applicant or publication searches, this general free-text search is clearly distinguished.
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 use case tag ('Technologie-/Innovationsrecherche in Schweizer Patenten') which provides context, but does not explicitly state when not to use this tool or mention specific alternatives like the sibling search tools for applicants or publications.
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, destructiveHint=false, idempotentHint=true, openWorldHint=true. Description adds value by stating it returns a JSON string with quota details (used and remaining volume) and explains the monthly quota behavior. 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?
Description is concise: one sentence for the main action, a use_case tag, an explanatory note, and return type. Every sentence adds value. Slightly longer due to the tag, but still efficient.
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 parameterless tool with full annotation coverage and an output schema, the description is complete. It explains purpose, usage context, and output details. No gaps remain.
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?
Tool has 0 parameters, and schema coverage is 100% (empty schema). Description does not need to add parameter details. Baseline of 4 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 it checks the remaining data transfer quota of the IGE Swissreg API, using a specific verb ('Prüft') and resource. It is distinguished from sibling tools (search tools) by focusing on quota monitoring rather than patent/trademark searches.
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?
Includes a <use_case> tag explicitly indicating when to use it: 'Betriebsueberwachung: verbleibendes API-Kontingent pruefen.' Also explains the monthly quota and monitoring context. Does not mention alternatives or when not to use, but given sibling tools are all search tools, the usage context is clear.
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, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds behavioral details about return structure (source, total, count, results, next_page_token) and pagination, which complements the annotations without contradiction.
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, with a clear purpose, use case tag, and args section. It front-loads the main action. Minor redundancy (repeats 'Innovationsmonitoring') but overall 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?
The description covers input parameters with examples and outlines the return structure, which is sufficient for a search tool. It does not mention error handling or edge cases, but given the presence of an output schema (implied) and straightforward functionality, it is reasonably complete.
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?
Despite schema description coverage being 0%, the description explicitly lists all parameters with explanations and examples (e.g., 'ABB*' for applicant_name, pagination details for page_size and page_token). This adds significant meaning beyond the schema's basic type and constraint information.
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: searching Swiss patents by applicant or inventor. It specifies the verb 'search' and resource 'Swiss patents by applicant', and includes a use case tag ('Innovationsmonitoring'), distinguishing it from sibling tools that search by other criteria.
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 usage context ('useful for competitive analysis and innovation monitoring') and includes a use case tag, but does not explicitly state when not to use the tool or suggest alternatives. It gives clear context without exclusions.
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-ip-mcp MCP server](https://glama.ai/mcp/servers/malkreide/swiss-ip-mcp/badges/card.svg)](https://glama.ai/mcp/servers/malkreide/swiss-ip-mcp)

Score Badge

Copy to your README.md:

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

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