swiss-ip-mcp provides read-only, AI-friendly access to the Swiss intellectual property register (Swissreg), operated by the Swiss Federal Institute of Intellectual Property (IGE/IPI), covering trademarks, patents, patent publications, and supplementary protection certificates (SPC).
Trademark tools
Search trademarks by free text (with wildcard * support), owner name, or Nice classification class (1–45)
Retrieve a specific trademark by registration number (status, Nice classes, registration history)
Patent tools
Search patents by free text, applicant/inventor name, or technology area
Retrieve a specific patent by number (IPC codes, applicants, inventors, status)
Search official Swiss patent publications for prior-art research
Supplementary Protection Certificates (SPC/ESZ)
Search SPCs for pharmaceutical and plant-protection products
Cross-domain & operational tools
Filter recent filings by date range across all IP domains (trademarks, patents, patent publications, SPCs)
Check remaining monthly API data transfer quota
Additional capabilities
Resources: Access server and data-source metadata via swissip://about and swissip://domains
Prompts: Curated workflow templates for trademark availability checks, competitor IP reports, and recent filings reports
Pagination: All search tools support paginated results
Provenance: Every response includes source, provider, URL, and license attribution
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@swiss-ip-mcp Search for patents filed by ETH Zurich."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
🇨🇭 Part of the Swiss Public Data MCP Portfolio
MCP Server for Swiss Intellectual Property Data (IGE/IPI)
🇩🇪 Deutsche Version → README.de.md
swiss-ip-mcp is a Model Context Protocol (MCP) server that gives AI models structured, language-driven access to the Swiss intellectual property register Swissreg, operated by the Swiss Federal Institute of Intellectual Property (IGE/IPI).
It is the successor to patent-mcp and covers all available domains of the Swissreg Datadelivery API: trademarks, patents, patent publications, and supplementary protection certificates (SPC/ESZ).
This server is model-agnostic. It works with Claude, GPT-4, Llama, and any other MCP-compatible client – not just Claude Desktop.
Related MCP server: swiss-courts-mcp
The real power is natural language. Instead of manually searching the register, just ask a question:
"Which trademarks does the City of Zurich hold at the IGE?"
"Is the name 'Learning City Zurich' registered as a trademark in Switzerland?"
"Which pharmaceutical companies have filed Swiss patents in the last six months?"
"Show me all trademark applications in the education sector (Nice class 41) since January 2025."
"What supplementary protection certificates does Novartis hold in Switzerland?"
Domain | Description |
Trademarks | Swiss trademark register – filing, protection, owners, Nice classes |
Patents | CH patents – filing, grant, IPC classes, applicants, inventors |
Patent publications | Official patent publications in the Swiss Official Gazette |
SPC / ESZ | Supplementary protection certificates for medicinal and plant-protection products |
Note: Design search is not yet available in the Swissreg Datadelivery API.
Tool | Function |
| Free-text trademark search (wildcard |
| Retrieve a trademark by registration number |
| Find all trademarks held by a given owner |
| Filter trademarks by Nice classification class |
| Free-text patent search |
| Retrieve a patent by number |
| Find patents by applicant or inventor name |
| Search patent publications |
| SPC/ESZ search (pharma and plant protection) |
| Filter filings by date range across all domains |
| Check remaining API data transfer quota |
Beyond tools, the server exposes two more MCP primitives:
Resources (read-only metadata, swissip:// URI scheme):
URI | Content |
| Server + data-source metadata (provenance, covered domains) |
| List of covered IP domains |
Prompts (curated workflow templates):
Prompt | Arguments | Purpose |
|
| Check whether a name is a registered Swiss trademark |
|
| IP overview (trademarks + patents) for a company |
|
| Report on recent filings in a period |
Tool execution errors (API failures, timeouts, missing credentials) are
returned with MCP isError: true and a masked, user-friendly message — internal
details (stack traces, raw API bodies) go only to the server log. A specific
number lookup that finds nothing is not an error: it returns a normal result
with match_type: "none" and a message.
This server is in Phase 1 (read-only) of the MCP phased-rollout model: every
tool is read-only and writes nothing. See ROADMAP.md for the
phase plan and the prerequisites for any future write-capable phase.
AI client (Claude Desktop, Cursor, VS Code + Continue, …)
│
│ MCP (stdio or SSE)
▼
swiss-ip-mcp
│
│ HTTPS + OAuth2 (IGE IDP)
▼
Swissreg Datadelivery API
https://www.swissreg.ch/public/api/v1
│
├── TrademarkSearch
├── PatentSearch
├── PatentPublicationSearch
├── SPCSearch
└── UserQuotaTransport | Use case | Configuration |
stdio | Claude Desktop, local development | Default (no extra setup) |
Streamable HTTP | Cloud deployment (Render.com etc.) |
|
SSE | Legacy HTTP clients |
|
Transport is selected at startup from the MCP_TRANSPORT environment variable
(default stdio). The HTTP transports are served by uvicorn and honour:
Variable | Default | Purpose |
|
| Bind address. Use |
|
| Bind port ( |
| (empty) | Comma-separated CORS origin allow-list. No wildcard in production. |
| (empty) | Comma-separated |
The Mcp-Session-Id header is exposed via CORS so browser-based clients can
read and echo it on follow-up requests.
IGE credentials (free): Sign the terms of use and send the form by post to the IGE. Credentials are issued upon receipt.
Python 3.11 or later
uv (recommended) or pip
# Run directly with uv (recommended, no local installation needed)
uvx swiss-ip-mcp
# Local development installation
git clone https://github.com/malkreide/swiss-ip-mcp
cd swiss-ip-mcp
pip install -e ".[dev]"export IGE_USERNAME="your_username"
export IGE_PASSWORD="your_password"Open the config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"swiss-ip": {
"command": "uvx",
"args": ["swiss-ip-mcp"],
"env": {
"IGE_USERNAME": "your_username",
"IGE_PASSWORD": "your_password"
}
}
}
}swiss-ip-mcp is compatible with any MCP-capable client:
Client | Configuration |
Cursor | Add to |
VS Code + Continue | Add via |
Windsurf | Add via MCP server settings |
Self-hosted (mcp-proxy) | Use SSE transport with |
MCP_TRANSPORT=streamable-http \
MCP_HOST=0.0.0.0 PORT=8000 \
MCP_ALLOWED_ORIGINS="https://your-client.example" \
MCP_ALLOWED_HOSTS="your-app.onrender.com" \
IGE_USERNAME=... IGE_PASSWORD=... \
swiss-ip-mcpSecurity note: bind to
0.0.0.0only inside a container or behind a reverse proxy. Always setMCP_ALLOWED_ORIGINSandMCP_ALLOWED_HOSTSfor public deployments — this enables CORS scoping and DNS-rebinding protection. The endpoint is unauthenticated and serves only public IP-register data; do not place credentialed or non-public tools behind this transport without adding authentication first.
A hardened multi-stage Dockerfile (non-root UID 10001,
HEALTHCHECK on /health), a docker-compose.yml with
resource limits, and Kubernetes manifests + an HAProxy sticky-session config
under deploy/ are included.
docker compose up --build # reads IGE_* from .envSee docs/deployment.md for hardening, resource limits and
scaling (stateless vs. sticky-session) details.
# Unit tests (no credentials needed)
PYTHONPATH=src pytest tests/ -v
# Including live integration tests against the real API
IGE_USERNAME=... IGE_PASSWORD=... PYTHONPATH=src pytest tests/ -vThe CI workflow runs on Python 3.11, 3.12, and 3.13.
The server can emit OpenTelemetry traces — one span per tool call plus child spans for the backend Swissreg/IDP HTTP calls. Tracing is off by default and adds no overhead until enabled.
pip install 'swiss-ip-mcp[otel]'
MCP_OTEL_ENABLED=1 \
OTEL_EXPORTER_OTLP_ENDPOINT=http://your-collector:4318 \
MCP_ENV=production \
swiss-ip-mcpVariable | Purpose |
| Set to |
| OTLP/HTTP collector endpoint (standard OTEL variable). |
| Value for the |
Tool spans carry only mcp.tool.name and mcp.tool.result.is_error — no
query arguments, credentials or response bodies are recorded.
The server logs structured JSON to stderr (stdout is reserved for the
stdio protocol). Every tool call binds a tool name and a correlation_id, so
all log lines for one call are correlated. Set the level with LOG_LEVEL
(DEBUG / INFO / WARNING / ERROR, default INFO):
{"event": "tool.call.start", "tool": "swiss_ip_search_trademarks", "correlation_id": "da55…", "level": "info", "timestamp": "…Z"}This server speaks two protocol eras over the same endpoint. The client's first request on a connection decides which one applies; a later claim from the other era is refused.
Era | Revision | Who reaches it |
|
| What today's clients speak. The server answers with the revision asked for, or with the |
Per-request envelope |
| A request carrying the |
Both revisions are pinned in
tests/test_protocol_version.py and asserted
against the installed SDK, so a Dependabot bump of mcp cannot move either one
silently. This server builds no ASGI app to send an initialize through, so
the gate asserts the SDK constants rather than a measured response — the
weaker form, named rather than left unsaid.
Note that the SDK's LATEST_PROTOCOL_VERSION is an alias for the modern
era, not for the handshake era — pinning against it alone would leave the era
that current clients actually negotiate free to drift.
Update policy. When the gate fails, do not edit the constant blindly: read
the spec changelog between the two revisions, verify the server still behaves,
then move the constant, this section, README.de.md and
CHANGELOG.md together.
All data is provided by the IGE/IPI Swissreg Datadelivery API. The API is free after signing the usage terms, subject to a monthly data transfer quota. Check your remaining quota at any time using the swiss_ip_get_quota tool.
Field | Value |
Provider | Swiss Federal Institute of Intellectual Property (IGE/IPI) |
Source | Swissreg Datadelivery API — https://www.swissreg.ch/public/apidocs/ |
License / terms |
Provenance: every tool response carries a source block (provider, source
URL, license) so downstream consumers retain attribution. The result envelope is
{ source, total, count, match_type, results, next_page_token }.
Read-only: All tools perform authenticated POST requests to the Swissreg API — no data is written, modified, or deleted on any system.
No personal data: The API returns public IP register entries (trademark names, patent titles, applicant organisations). No personally identifiable information (PII) is processed or stored by this server beyond what the IGE API returns in its public records.
Rate limits & quota: The IGE Swissreg API enforces a monthly data transfer quota per account. Use the swiss_ip_get_quota tool to monitor remaining quota. The server enforces a 60s timeout per request. Avoid large page_size values (>20) for exploratory queries.
Authentication: Credentials (IGE_USERNAME, IGE_PASSWORD) are read from environment variables at runtime and never logged or persisted.
Terms of service: Data is subject to the IGE Swissreg Datadelivery API terms of use. A signed usage agreement with IGE/IPI is required before API access is granted.
Address list verified without credentials (2026-08-08). Every address, the Keycloak realm and the client_id this server builds are the ones the source publishes. A null result — and recorded as one, because a null result nobody wrote down is not one on the next pass. Three independent proofs, because one would not have carried:
The IDP discriminates: realms/egov with wrong credentials → invalid_grant ("Invalid user credentials"); an invented realm → 404 "Realm does not exist"; an invented client_id → invalid_client. So realm and client exist and only the credentials are missing.
The realm declares its own token endpoint under .well-known/openid-configuration — identical to the URL built here.
The official API documentation states both addresses verbatim, including the client_id as a "constant string".
Why the third proof is needed: the Swissreg API itself does not discriminate. A POST without a token returns 403, with an invented token 401 — and a freely invented path under /public/api/ returns exactly the same. A status code proves nothing there. scripts/record_fixtures.py re-measures this on every run and aborts if a control stops discriminating.
Response payloads are not recorded. They need credentials; PROVENANCE.md lists them as NOT RECORDED with the measured status rather than giving them a date they never had. What stays unproven is the shape of the responses — whether the XML fields are named as the parser reads them.
No guarantees: This server is a community project, not affiliated with the Swiss Federal Institute of Intellectual Property (IGE/IPI). Availability depends on upstream API uptime.
Server | Content |
City of Zurich open data (CKAN, weather, parking, geodata) | |
Swiss federal law via Fedlex SPARQL | |
Public transport, disruptions, tickets, train formations | |
Shared mobility, EV charging stations, traffic data | |
UNESCO / OECD education data | |
⚠️ Deprecated – superseded by this server |
See CONTRIBUTING.md (Deutsch) for how to
report bugs and submit changes.
See SECURITY.md for the security posture, hardening summary, and how to report a vulnerability.
MIT License — see LICENSE
Hayal Oezkan · github.com/malkreide
Run via uv's uvx — no clone or manual install needed. Add to your MCP client config (mcpServers for Claude Desktop, Cursor and Windsurf; use a top-level servers key for VS Code in .vscode/mcp.json):
{
"mcpServers": {
"swiss-ip-mcp": {
"command": "uvx",
"args": [
"swiss-ip-mcp"
],
"env": {
"IGE_USERNAME": "<your IGE_USERNAME>",
"IGE_PASSWORD": "<your IGE_PASSWORD>"
}
}
}
}Requires credentials: set IGE_USERNAME, IGE_PASSWORD (replace the placeholder values above).
Ruft ein bestimmtes Schweizer Patent anhand seiner Nummer ab. Detail-Abruf eines Patents per Nummer. Exakter Lookup; kein Fuzzy-Match. Gibt vollständigen Datensatz inkl. IPC-Codes, Anmelder, Erfinder und Status zurück.
Args: params (PatentNumberInput): Enthält: - patent_number (str): Schweizer Patentnummer, z.B. 'CH123456'
Returns: str: Ergebnis mit source, total, count, results (einzelner Eintrag), next_page_token
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| count | No | |
| total | No | |
| source | No | |
| message | No | |
| results | No | |
| date_range | No | |
| match_type | No | |
| suggestion | No | |
| next_page_token | No | |
| nice_class_searched | No |
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.
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.
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.
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.
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.
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.
Prüft das verbleibende Datentransfer-Kontingent der IGE Swissreg API. Betriebsueberwachung: verbleibendes API-Kontingent pruefen. Die API hat ein monatliches Kontingent. Damit lässt sich die Nutzung überwachen.
Returns: str: JSON mit Kontingent-Details inkl. genutztem und verbleibendem Volumen
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| quota | No | |
| source | No |
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.
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.
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.
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.
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.
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.
Ruft eine bestimmte Schweizer Marke anhand der Anmelde-/Registernummer ab. Detail-Abruf einer Marke per Anmelde-/Registernummer. Exakter Lookup; bei unbekannter Nummer match_type="none". Gibt detaillierten Datensatz inkl. Status, Waren-/Dienstleistungsklassen und Registrierungshistorie zurück.
Args: params (TrademarkNumberInput): Enthält: - trademark_number (str): Schweizer Markennummer, z.B. 'P-756123'
Returns: str: Ergebnis mit source, total, count, results (einzelner Eintrag), next_page_token
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| count | No | |
| total | No | |
| source | No | |
| message | No | |
| results | No | |
| date_range | No | |
| match_type | No | |
| suggestion | No | |
| next_page_token | No | |
| nice_class_searched | No |
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.
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.
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.
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.
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.
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.
Durchsucht Schweizer Patentpublikationen (offizielle Veröffentlichungen). Stand-der-Technik-Recherche ueber Patentpublikationen. Nützlich für Stand-der-Technik-Recherchen und Innovationsmonitoring.
Args: params (PatentSearchInput): Enthält: - query (str): Suchbegriff - page_size (int): Ergebnisse pro Seite - page_token (str): Paginierungs-Token
Returns: str: Ergebnis mit source, total, count, results, next_page_token
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| count | No | |
| total | No | |
| source | No | |
| message | No | |
| results | No | |
| date_range | No | |
| match_type | No | |
| suggestion | No | |
| next_page_token | No | |
| nice_class_searched | No |
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.
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.
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.
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.
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.
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.
Durchsucht das Schweizer Patentregister nach Freitext. Technologie-/Innovationsrecherche in Schweizer Patenten. Gibt CH-Patenteinträge inkl. Titel, Anmelder, IPC-Klassifikation, Daten und Rechtsstatus zurück.
Args: params (PatentSearchInput): Enthält: - query (str): Suchbegriff, z.B. 'solar energy*', 'Novartis' - page_size (int): Ergebnisse pro Seite (1–50) - page_token (str): Paginierungs-Token - sort_descending (bool): Neueste zuerst
Returns: str: Ergebnis mit source, total, count, results, next_page_token
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| count | No | |
| total | No | |
| source | No | |
| message | No | |
| results | No | |
| date_range | No | |
| match_type | No | |
| suggestion | No | |
| next_page_token | No | |
| nice_class_searched | No |
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.
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.
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.
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.
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.
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.
Durchsucht Schweizer Patente nach Anmelder oder Erfinder. Innovationsmonitoring: Patente eines Anmelders/Erfinders. Nützlich für Wettbewerbsanalyse und Innovationsmonitoring.
Args: params (PatentApplicantInput): Enthält: - applicant_name (str): Name, z.B. 'ABB*', 'ETH Zürich*', 'Roche*' - page_size (int): Ergebnisse pro Seite - page_token (str): Paginierungs-Token
Returns: str: Ergebnis mit source, total, count, results, next_page_token
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| count | No | |
| total | No | |
| source | No | |
| message | No | |
| results | No | |
| date_range | No | |
| match_type | No | |
| suggestion | No | |
| next_page_token | No | |
| nice_class_searched | No |
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.
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.
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.
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.
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.
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.
Durchsucht Schweizer IP-Eintragungen innerhalb eines Datumsbereichs. Zeitraum-/Trendanalyse neuer IP-Eintragungen je Schutzrecht. date_to ist exklusiv; ip_type aus 4 Werten. Unterstützt Marken, Patente, Patentpublikationen und ESZ.
Args: params (DateRangeInput): Enthält: - ip_type (str): 'trademark', 'patent', 'patent_publication', 'spc' - date_from (str): Startdatum YYYY-MM-DD (inklusive) - date_to (str): Enddatum YYYY-MM-DD (exklusive) - page_size (int): Ergebnisse pro Seite - page_token (str): Paginierungs-Token
Returns: str: Ergebnis mit source, total, count, results, next_page_token, date_range
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| count | No | |
| total | No | |
| source | No | |
| message | No | |
| results | No | |
| date_range | No | |
| match_type | No | |
| suggestion | No | |
| next_page_token | No | |
| nice_class_searched | No |
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.
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.
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.
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.
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.
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.
Durchsucht Schweizer Ergänzende Schutzzertifikate (ESZ / SPC). Pharma/Pflanzenschutz: ESZ/SPC recherchieren. ESZ verlängern den Patentschutz für Arzneimittel und Pflanzenschutzmittel.
Args: params (SpcSearchInput): Enthält: - query (str): Suchbegriff, z.B. 'Novartis', 'ibuprofen*' - page_size (int): Ergebnisse pro Seite - page_token (str): Paginierungs-Token
Returns: str: Ergebnis mit source, total, count, results (ESZ-Einträge), next_page_token
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| count | No | |
| total | No | |
| source | No | |
| message | No | |
| results | No | |
| date_range | No | |
| match_type | No | |
| suggestion | No | |
| next_page_token | No | |
| nice_class_searched | No |
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.
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.
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.
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.
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.
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.
Durchsucht das Schweizer Markenregister nach Freitext. Markenrecherche / Brand-Monitoring per Name, Wort oder Stichwort. Findet Marken nach Name, Markenbegriff oder Stichwort. Wildcards (*) möglich.
Args: params (TrademarkSearchInput): Enthält: - query (str): Suchbegriff, z.B. 'Zürich*', 'apple', 'Bank*' - page_size (int): Ergebnisse pro Seite (1–50, Standard 10) - page_token (str): Paginierungs-Token für Folgeseiten - sort_descending (bool): Neueste zuerst (Standard True)
Returns: str: Ergebnis mit source, total, count, results, next_page_token
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| count | No | |
| total | No | |
| source | No | |
| message | No | |
| results | No | |
| date_range | No | |
| match_type | No | |
| suggestion | No | |
| next_page_token | No | |
| nice_class_searched | No |
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.
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.
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.
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.
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.
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.
Durchsucht Schweizer Marken nach Nizza-Klassifikation. Branchenanalyse: Marken einer Nizza-Klasse (1-45) finden. Nützlich für Wettbewerbsanalysen innerhalb einer Branche.
Args: params (TrademarkClassInput): Enthält: - nice_class (int): Nizza-Klasse 1–45 - query (str): Optionaler zusätzlicher Textfilter - page_size (int): Ergebnisse pro Seite - page_token (str): Paginierungs-Token
Returns: str: Ergebnis mit source, total, count, results, next_page_token
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| count | No | |
| total | No | |
| source | No | |
| message | No | |
| results | No | |
| date_range | No | |
| match_type | No | |
| suggestion | No | |
| next_page_token | No | |
| nice_class_searched | No |
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.
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.
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.
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.
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.
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.
Durchsucht Schweizer Marken gefiltert nach Inhaber / Anmelder. Portfolio-Analyse: alle Marken eines Inhabers/Anmelders finden. Nützlich für IP-Monitoring: alle Marken eines Unternehmens oder einer Person finden.
Args: params (TrademarkOwnerSearchInput): Enthält: - owner_name (str): Inhabername, z.B. 'Nestlé*', 'Stadt Zürich*' - page_size (int): Ergebnisse pro Seite (1–50) - page_token (str): Paginierungs-Token
Returns: str: Ergebnis mit source, total, count, results, next_page_token
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| count | No | |
| total | No | |
| source | No | |
| message | No | |
| results | No | |
| date_range | No | |
| match_type | No | |
| suggestion | No | |
| next_page_token | No | |
| nice_class_searched | No |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.4swiss_ip_get_patentswiss_ip_get_quotaswiss_ip_get_trademarkswiss_ip_search_patent_publicationsswiss_ip_search_patentsswiss_ip_search_patents_by_applicantswiss_ip_search_recent_filingsswiss_ip_search_spcswiss_ip_search_trademarksswiss_ip_search_trademarks_by_classswiss_ip_search_trademarks_by_ownerScored across 11 tools
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.
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.
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.
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.
MCP server for searching Airweave collections with natural language queries.
opendata.swiss MCP — Switzerland's federal open-data portal (CKAN catalogue).
MCP server for querying Forkast documentation
