This MCP server performs pre-filing trademark clearance searches for word and word/figurative marks across EU and national registers, with Nice classification checks and file note support.
Run a full clearance search (recherche_lauf): generate variants, query EU/AT/DE/CH/WO registers, deduplicate, sort by similarity, and return hits, search log, and gaps.
Search individual registers: EUIPO (eutm_search) and TMview (tmview_search) for national and WIPO marks.
Retrieve full trademark records (eutm_get, tmview_get) with goods/services, owner, status, deadlines, and office links.
Handle Nice classification: suggest terms (nizza_suggest), validate against EUIPO harmonized database (nizza_validate), and look up class headings (nizza_klassenueberschriften).
Inspect generated search variants (varianten) and check API access/status (marken_status).
Produce evidence-based results with register numbers, offices, owners, classes, status, and retrieval timestamps; explicitly flag search gaps.
Support drafting a file note via a provided system prompt. It does not cover pure figurative marks, unregistered rights, or replace official/commercial full searches.
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., "@mcp-markenrecherche Prüfe, ob 'Bergluft' als Marke in Österreich und der EU verfügbar ist."
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.
Vorrecherche für Marken mit Wortbestandteil — in der EU und in nationalen Registern, direkt aus dem Chat.
Ein MCP-Server für die Kanzlei: Du sagst deinem Sprachmodell (Claude Desktop, Cherry Studio, Msty …), welches Zeichen du für welche Waren oder Dienstleistungen prüfen willst, und bekommst eine belegte Trefferliste, einen Klassifizierungsvorschlag und am Ende einen Aktenvermerk. Die rechtliche Beurteilung bleibt bei dir. Kein Treffer wird erfunden, jede Lücke wird benannt.
Pre-filing clearance search for word and word/figurative marks (EUIPO API, TMview, Nice classification) as an MCP server. German documentation — the target audience is Austrian and German-speaking practitioners.
Eine Recherche in einem Satz. „Prüf mir KIRVO für Software und IT-Beratung in Österreich und der EU." Das Modell klassifiziert, lässt den Server die Register abfragen, zieht für die kritischen Treffer den Vollauszug und schreibt den Aktenvermerk — mit Ampel je Treffer, Suchprotokoll und den offenen Punkten.
Belegte Treffer statt Modellwissen. Jeder Treffer trägt Registernummer, Amt, Inhaber, Klassen, Status, Anmeldetag und den Abrufzeitpunkt aus dem Register. Was der Server nicht abfragen konnte, steht als Recherchelücke im Ergebnis — nie stillschweigend weggelassen.
Varianten, die du händisch nie alle suchen würdest. Der Server bildet aus dem Zeichen Wortstämme, Schreibweisen (C/K, PH/F, Doppelkonsonanten …), Wildcards und lautgleiche Wortanfänge und fragt jede Variante ab. Ein Kunstwort wie KIRVO liefert so auch CIRVO, GIRVO oder KIRBO, ein zusammengesetztes Zeichen auch die Serienmarken mit demselben Stamm. Die Treffer werden nach Schriftbild und Klang sortiert, die ähnlichsten zuerst.
Klassifizierung gegen die amtliche Datenbank. „Welche Klassen und Begriffe für ein Unternehmen, das Physiotherapie und Trainingsgeräte anbietet?" — das Modell schlägt vor, der Server prüft jeden Begriff gegen die harmonisierte Datenbank der EUIPO und sagt, ob er so akzeptiert wird oder ein Beanstandungsrisiko trägt.
Ein Aktenvermerk, der im Akt bestehen kann. Auftrag, Rechercheumfang, Klassifizierung,
Trefferübersicht, Bewertung der gelben und roten Treffer nach § 10 MSchG / Art 8 UMV, absolute
Eintragungshindernisse, Empfehlung, Recherchelücken, Suchprotokoll. Der Systemprompt dafür
liegt bei (prompts/systemprompt_beispiel.md).
Related MCP server: patent-mcp
Das ist eine Vorrecherche. Sie sagt dir, ob eine amtliche Ähnlichkeitsrecherche oder eine kommerzielle Vollrecherche nötig ist — sie ersetzt keine von beiden.
Gefunden wird nur, was einen Wortbestandteil hat. Reine Bildmarken und die grafische Seite von Wort-Bild-Marken bleiben außen vor. Nicht registrierte Kennzeichenrechte (Firmenwortlaut, Domains, Etablissementbezeichnungen) sind nicht abgedeckt. Und die nationalen Register laufen über TMview, das nur für gelegentliche Abfragen ausgelegt ist (Details unten).
„Welche Nizza-Klassen kommen für ein Unternehmen in Frage, das Mähroboter verkauft und wartet?"
„Prüf das Zeichen SARUMO für Kosmetik und Nahrungsergänzung, Gebiet Österreich und EU."
„Gibt es in Klasse 30 ältere Marken, die wie VANDELIX klingen?"
„Zieh mir den Vollauszug zu 018512783 und sag mir, ob das Verzeichnis mit Software-Wartung kollidiert."
„Ist ‚Software-Wartung für Zahnärzte' ein harmonisierter Begriff in Klasse 42?"
Das Modell entscheidet selbst, welche Werkzeuge es dafür braucht. Für eine vollständige
Recherche ist recherche_lauf der Kern; alles andere sind Einzelabfragen und Vollauszüge.
Du brauchst Python ab 3.12, uv und einen EUIPO-Zugang.
EUIPO-Zugang. Auf https://dev.euipo.europa.eu mit deinem EUIPO-Konto einloggen, eine App anlegen und die Produkte Trademark search und Goods And Services abonnieren. „Key" ist die Client-ID. Die EUIPO schaltet die Subscriptions nach Prüfung frei (Pass und Adressnachweis werden verlangt); bis dahin antwortet die API mit 403. Zum Testen gibt es ein eigenes Sandbox-Portal (https://dev-sandbox.euipo.europa.eu) mit eigenen Keys und eingefrorenem Datenbestand — Sandbox-Treffer gehören in keinen Aktenvermerk.
Konfiguration. .env.example nach .env kopieren und Keys eintragen:
EUIPO_CLIENT_ID=…
EUIPO_CLIENT_SECRET=…
EUIPO_ENV=production # oder sandbox (dann EUIPO_SANDBOX_CLIENT_ID/_SECRET)Im Chat-Programm eintragen. Claude Desktop und Cherry Studio nehmen denselben Eintrag
(Cherry: „Add Server → Import from JSON"; bei Cherry den absoluten Pfad zu uv verwenden,
which uv zeigt ihn):
{
"mcpServers": {
"marken": {
"command": "uv",
"args": ["--directory", "/pfad/zu/mcp-markenrecherche", "run", "python", "src/server.py"]
}
}
}Beim ersten Start richtet uv die Umgebung selbst ein.
Systemprompt. prompts/systemprompt_beispiel.md in den Assistenten kopieren, die
Platzhalter (Kanzlei, Anwalt, Ich- oder Wir-Form) ausfüllen. Ohne Prompt funktionieren die
Werkzeuge auch, aber der Aktenvermerk kommt erst mit ihm in Form.
Erste Probe: „Prüf bitte den Zugang" — das Modell ruft marken_status auf und meldet, ob
EUIPO und TMview erreichbar sind.
Werkzeug | Was es tut |
| Der vollständige Lauf: Varianten bilden, Register abfragen, deduplizieren, nach Ähnlichkeit sortieren; liefert Trefferliste, Suchprotokoll und Recherchelücken. |
| Vollauszug einer EU-Marke bzw. einer nationalen Marke mit Waren-/Dienstleistungsverzeichnis, Inhaber, Status, Fristen |
| Klassifizierung: Begriffe vorschlagen, gegen die harmonisierte Datenbank prüfen, Klassenüberschriften nachschlagen |
| Einzelabfragen und Einblick, welche Varianten der Lauf bildet |
| Zugang und Erreichbarkeit prüfen |
EUIPO (Unionsmarken und internationale Registrierungen mit EU-Benennung) über die offiziellen APIs Trademark Search und Goods and Services. Stabil, vollständig, mit Verzeichnis.
TMview (nationale Register wie AT, DE, CH sowie WIPO) über die Schnittstelle, die die TMview-Weboberfläche selbst benutzt. Es gibt dafür keine dokumentierte API; sie kann sich ohne Ankündigung ändern, und die Nutzungsbedingungen von tmdn.org sind auf manuelle Nutzung ausgelegt. Der Server hält deshalb 1,5 Sekunden Pause zwischen den Anfragen, stellt je Lauf nur wenige, und hört beim ersten Anzeichen einer Sperre sofort auf — dann steht das im Ergebnis als Lücke, und du prüfst das nationale Register von Hand nach. Zwei, drei Recherchen am Tag sind unauffällig; Serienläufe sind es nicht. Nutzung auf eigene Verantwortung.
Jeder Treffer bekommt einen Wert zwischen 0 und 1 aus Schriftbild (Editierdistanz), Klang (Kölner Phonetik) und der Frage, ob das eine Zeichen im anderen enthalten ist; bei Mehrwortzeichen zählt der Durchschnitt der prägenden Bestandteile. Ab 0,85 gilt ein Treffer als „hoch", ab 0,65 als „mittel". Der Wert ist eine Sortierhilfe: Er sagt, wo du zuerst hinschaust, nicht, ob Verwechslungsgefahr besteht. Das entscheidet die Bewertung nach Zeichen- und Warenähnlichkeit, Kennzeichnungskraft und Publikum — und die machst du.
Python 3.12, FastMCP, httpx. Tests: uv run --extra dev pytest. Die Variantenlogik liegt in
src/varianten.py, die Anbindungen in src/euipo_client.py und src/tmview_client.py, die
Werkzeuge in src/server.py. Statusfilter, Nachfrist bei abgelaufenen Marken (Art 53 Abs 3
UMV), Deduplizierung von IR mit EU-Benennung und die Erkennung des TMview-Bot-Schutzes sind im
Code kommentiert. Die Antworten der Werkzeuge sind deutsch beschriftet; die erste Zeile jeder
Werkzeugbeschreibung trägt ein englisches Stichwort, damit auch englisch angesprochene Modelle
das richtige Werkzeug finden.
MIT — siehe LICENSE. Keine Gewähr für Vollständigkeit oder Richtigkeit der
Rechercheergebnisse.
[EU trade mark record] Vollständiger Registerauszug einer Unionsmarke / IR mit EU-Benennung nach Anmeldenummer (z. B. 018945321 oder W01234567). Enthält das Waren-/Dienstleistungsverzeichnis je Klasse.
| Name | Required | Description | Default |
|---|---|---|---|
| nummer | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden. It discloses that the tool returns a complete extract and includes the class-wise Waren-/Dienstleistungsverzeichnis, but it does not address error behavior, authorization, or side effects. The read-only nature is inferable from 'Get' and 'Registerauszug' but not explicit.
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 two short sentences, front-loads the core purpose ('Vollständiger Registerauszug ... nach Anmeldenummer'), and every clause adds information. No redundant filler.
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 one-parameter read tool with an output schema, the description is nearly complete: it defines the input and the key content of the result. It only lacks explicit routing to or away from sibling tools and error-case behavior, which are minor for the core call.
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 coverage is 0%, but the description fully compensates for the single parameter by explaining that 'nummer' is the application number and giving concrete examples ('018945321 oder W01234567'). This removes ambiguity about format and accepted input.
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 that the tool returns the complete register extract ('Vollständiger Registerauszug') for an EU trade mark or IR with EU designation, identified by application number. It also adds the distinguishing detail that it contains the goods/services list per class, which separates it from sibling status and search tools.
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 is implied: pass an application number when you need a full EU trade mark extract with class-wise goods/services. However, it does not explicitly say when to prefer this over marken_status, tmview_get, or eutm_search, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[EU trade mark search] Einzelne Abfrage der EUIPO-Datenbank (Unionsmarken und internationale Registrierungen mit EU-Benennung). modus: exakt | beginnt | enthaelt | roh (zeichen wird als RSQL-Wert mit eigenen * verwendet). Liefert Trefferliste mit Registernummer, Inhaber, Klassen, Status. Für die vollständige Recherche recherche_lauf verwenden.
| Name | Required | Description | Default |
|---|---|---|---|
| modus | No | enthaelt | |
| klassen | No | ||
| zeichen | Yes | ||
| nur_lebend | No | ||
| max_treffer | No | ||
| nur_wortmarken | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It does disclose that the tool returns a hit list with register number, owner, classes, and status, and it explains the special 'roh' mode behavior. However, it does not mention result limits, default filtering behavior, or other response details, leaving some behavioral aspects to inference.
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 compact and front-loads the key purpose before mode details, output fields, and the sibling alternative. The bracketed '[EU trade mark search]' is somewhat redundant with the title, but overall the description is dense and free of filler.
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 provides enough for basic usage: scope, mode options, return fields, and a routing hint to recherche_lauf. However, with six parameters and zero schema-level documentation, the lack of explanation for the optional filters and limits leaves gaps that the output schema only partially fills.
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%, so the description must compensate. It only explains 'modus' and its allowed values, including the raw RSQL mode. The other five parameters (zeichen, klassen, nur_lebend, max_treffer, nur_wortmarken) are not described in the tool description and must be inferred from their names or the bare 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 a specific action ('Einzelne Abfrage der EUIPO-Datenbank') and a clear scope (EU trademarks and international registrations with EU designation). It also distinguishes the tool from the sibling recherche_lauf by noting that complete searches should use that tool instead.
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 explicitly says 'Für die vollständige Recherche recherche_lauf verwenden', which tells the agent when not to use this tool and which alternative to pick. The phrase 'Einzelne Abfrage' also clarifies that this is for single ad-hoc queries, not full searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[status] Prüft Konfiguration und Erreichbarkeit der EUIPO-API (Umgebung, Credentials, Token). Immer zuerst aufrufen, wenn ein Recherchelauf fehlschlägt.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It transparently states that the tool checks configuration and API reachability rather than performing a search or mutation. It does not explicitly state side-effects are absent, but 'status' and 'Prüft' strongly imply a non-destructive diagnostic operation.
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 two short sentences with no filler. The first sentence states what the tool does, and the second provides a concrete trigger for use. Every word earns its place.
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 zero-parameter status/diagnostic tool with an output schema and a clear usage rule, the description is complete. It tells the agent what is checked, what system is involved, and when to call it. The output schema covers return-value details.
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 tool has zero parameters and schema coverage is complete, so there is nothing for the description to add about parameters. The baseline of 4 applies because parameter semantics are not a concern here.
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 uses a specific verb ('Prüft') and names the exact resource (EUIPO-API configuration and reachability), with concrete aspects enumerated (Umgebung, Credentials, Token). This clearly distinguishes it from the sibling search and retrieval tools.
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?
It explicitly states when to call this tool first: whenever a search run fails. This gives the agent a clear decision rule and positions it as a diagnostic prerequisite, which is exactly the kind of usage guidance needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[Nice class headings] Amtliche Klassenüberschriften der Nizza-Klassifikation (alle 45 oder Auswahl) — zur Orientierung über den Ähnlichkeitsbereich, nicht als Verzeichnis (Klassenüberschriften decken seit IP Translator nicht die ganze Klasse ab).
| Name | Required | Description | Default |
|---|---|---|---|
| klassen | No | ||
| sprache | No | de |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does disclose that headings are official but non-exhaustive, which is meaningful behavioral context. It does not mention language behavior, selection semantics, or whether the operation is read-only, but the output schema likely covers return structure.
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 compact and front-loaded with the object and purpose. The caveat about IP Translator is integrated without unnecessary expansion. Minor redundancy exists with the bracketed English label, but it does not meaningfully hurt usability.
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 output schema supplies return-shape information, but the input semantics are incomplete for an agent that needs to invoke non-default behavior. The description does not clarify accepted sprache values or the exact relationship between klassen values and 'all 45 or selection'. This leaves moderate ambiguity for a tool with no annotation support and 0% schema description coverage.
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%, so the description must compensate. 'Alle 45 oder Auswahl' partially explains the klassen parameter but does not specify how to encode 'all' vs. a selection in the schema or what null means. The sprache parameter is not described at all, leaving a key input undocumented.
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 identifies the resource: official Nice Classification class headings, and states the purpose ('zur Orientierung über den Ähnlichkeitsbereich'). It also adds a key limitation ('nicht als Verzeichnis'), which helps distinguish it from a comprehensive classification lookup, though it does not explicitly differentiate it from sibling Nizza tools.
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 gives clear intended-use context: use for orientation about similarity range, not as an authoritative directory. It also warns that class headings do not cover the whole class since IP Translator, providing a when-not-to-rely-on-it signal. However, it does not explicitly direct the agent to alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[Nice classification suggestions] Klassifizierungsvorschlag: liefert zu einem Freitext (Ware/Dienstleistung im Klartext, z. B. 'Wartung von Software' oder 'Physiotherapie') die passenden harmonisierten Begriffe (TMclass/HDB) mit Nizza-Klasse. Zwei Wege in einem Aufruf: Vorschlagsliste der EUIPO und Volltextsuche in den Begriffen. Optional auf eine Klasse einschränken.
| Name | Required | Description | Default |
|---|---|---|---|
| klasse | No | ||
| sprache | No | de | |
| freitext | Yes | ||
| max_treffer | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses that the tool combines EUIPO suggestion list lookup and full-text search in a single call, and that an optional class filter exists. It does not cover output details or edge cases, but the output schema covers the return structure.
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 compact and well-structured: one dense sentence that starts with the core purpose, then adds the two-mode behavior and the optional class restriction. There is no redundant restatement of the title or filler 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?
With an output schema available and a relatively simple parameter set, the description provides the essential input semantics and behavioral model. It is slightly incomplete regarding usage routing and the two undocumented parameters, but it is adequate for an agent to 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?
Schema description coverage is 0%, so the description must compensate. It explains freitext as a free-text goods/services input and klasse as an optional class restriction, but it does not describe sprache or max_treffer, which are left to their names and defaults. This is only partial compensation for the missing schema descriptions.
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 uses a specific verb ('liefert') and a clear resource ('passenden harmonisierten Begriffen ... mit Nizza-Klasse') for a free-text goods/services input. It also distinguishes itself by naming the two lookup modes in one call, making it easy to tell apart from siblings like nizza_validate or nizza_klassenueberschriften.
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 clearly implies when to use the tool: when you have a free-text goods/services description and need Nice classification suggestions. However, it does not explicitly state when to prefer this tool over alternatives or mention any exclusions/conditions, so the usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[Nice classification validation] Prüft ein Waren-/Dienstleistungsverzeichnis gegen die harmonisierte Datenbank der EUIPO. begriffe im Format 'Klasse: Begriff' (z. B. '42: Wartung von Computersoftware'); mehrere Begriffe derselben Klasse einzeln angeben. Rückgabe je Begriff: harmonisiert ja/nein und formale Fehler. Nicht harmonisierte Begriffe sind im Bericht als Beanstandungsrisiko zu kennzeichnen (Klasse muss angegeben sein — ohne Klasse kein Eintrag).
| Name | Required | Description | Default |
|---|---|---|---|
| sprache | No | de | |
| begriffe | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It reveals per-term return semantics (harmonized yes/no and formal errors), the special report treatment of non-harmonized terms as objection risk, and the hard requirement that class must be supplied. This is substantial context beyond the tool name.
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 compact and front-loaded with the core purpose, then gives necessary input and output behavior. The final clause 'Klasse muss angegeben sein — ohne Klasse kein Eintrag' is slightly redundant, but overall every sentence contributes useful information.
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 does not need to detail return structure. It covers purpose, input format, required class, and validation-result behavior. Minor gaps remain around the 'sprache' parameter and potential batch or formatting limits, but the description is adequate 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%, so the description must compensate. It does explain the required 'begriffe' parameter in detail, including format and class requirement, but the optional 'sprache' parameter is never mentioned. The name and default 'de' hint at language, but the description still leaves one parameter undocumented.
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 a specific action and resource: 'Prüft ein Waren-/Dienstleistungsverzeichnis gegen die harmonisierte Datenbank der EUIPO' (validates a goods/services list against the harmonized EUIPO database). This clearly distinguishes it from sibling tools such as nizza_suggest (suggesting terms) and nizza_klassenueberschriften (class headings).
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 gives clear operational guidance: terms must be in 'Klasse: Begriff' format, multiple terms of the same class must be entered individually, and class is required ('ohne Klasse kein Eintrag'). It does not explicitly mention when to choose this tool over alternatives, but the validation context and input constraints are clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[trade mark clearance search — main tool] Vollständiger Recherchelauf in einem Aufruf über mehrere Register: bildet die Suchvarianten, fragt jede gegen die Register ab, dedupliziert, bewertet die Zeichenähnlichkeit (Schriftbild, Klang, Enthaltensein) und liefert EINE sortierte Trefferliste plus Suchprotokoll und Recherchelücken. register: Standard ["EU","AT"] — EU = Unionsmarken + IR mit EU-Benennung über die EUIPO-API; AT/DE/CH/WO/… = nationale Register bzw. WIPO über TMview. klassen: angemeldete UND angrenzende Klassen; ohne Klassen klassenübergreifend. zusatz_varianten: eigene Suchstrings (mit * als Wildcard), z. B. Übersetzungen. Treffer unter min_aehnlichkeit werden nur gezählt; gelistet werden höchstens max_gelistet (die ähnlichsten zuerst).
| Name | Required | Description | Default |
|---|---|---|---|
| umfang | No | normal | |
| klassen | No | ||
| zeichen | Yes | ||
| register | No | ||
| nur_lebend | No | ||
| max_gelistet | No | ||
| max_varianten | No | ||
| max_pro_variante | No | ||
| min_aehnlichkeit | No | ||
| zusatz_varianten | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it delivers: it discloses the full pipeline (variant generation, per-register querying, deduplication, similarity scoring), default registers, class handling, wildcard support, and the threshold/listing behavior for low-similarity hits. This goes well beyond a generic verb+resource statement.
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 dense but well structured: the first sentence states the core purpose and pipeline, followed by labeled clarifications for key parameters and thresholds. Every sentence adds meaningful operational information, and the format is easy to scan.
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 complex 10-parameter tool with no annotations, the description covers a lot: pipeline, defaults, edge-case behavior, and output contents. However, it leaves several parameters under-specified and does not reference sibling tools for routing. The output schema exists, so return-value details are not required, but the missing parameter semantics keep it from being fully 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%, so the description must compensate. It explains register, klassen, zusatz_varianten, min_aehnlichkeit, and max_gelistet, but several parameters remain unexplained: umfang, max_varianten, max_pro_variante, and nur_lebend. Some are guessable from names, but not enough clarity for an agent invoking all 10 params.
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 identifies this as the main trademark clearance search tool: a complete multi-register search that builds variants, queries registers, deduplicates, scores similarity, and returns one sorted hit list. It is clearly differentiated from sibling tools like tmview_get or eutm_search by being the aggregated 'main tool'.
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 makes the context clear: this is the comprehensive search across multiple registers, used when a full clearance search is needed. It does not explicitly name sibling alternatives or state when to prefer a direct register query, but the 'main tool' framing and multi-register scope provide strong usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[TMview record] Vollauszug einer Marke aus TMview nach ST13-Kennung (z. B. AT501972000001736), inkl. Waren-/Dienstleistungsverzeichnis, Inhaber, Vertreter, Widersprüche und Link zur Amtsseite (See-IP bei AT-Marken).
| Name | Required | Description | Default |
|---|---|---|---|
| st13 | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It transparently lists the included data (goods/services, owner, representative, oppositions, office link, See-IP for AT), which helps set expectations. However, it does not explicitly state that the operation is read-only, how errors like an invalid ST13 are handled, or any access constraints.
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 one dense sentence that front-loads the core action and then enumerates the returned components. It is efficient with no filler, though the long comma-separated list would be slightly easier to parse as structured bullets.
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 single-parameter retrieval tool with an output schema present, the description covers the essential behavior and output scope well. It lacks only marginal details such as error behavior or prerequisites, which are not critical for an agent to invoke the tool correctly with a valid ST13.
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%, and the description compensates by explaining st13 as an ST13-Kennung with a concrete example (AT501972000001736). This adds real meaning beyond the bare string type in the schema, though it could describe the ST13 format more formally.
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 names a specific verb-resource pair ('Vollauszug einer Marke aus TMview') and the lookup key (ST13-Kennung), and lists the returned record components. It distinguishes itself from search and EU-get siblings by the TMview scope and ST13 identifier, though it does not explicitly name a sibling for contrast.
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 is implied: call this tool when you have a specific ST13 identifier and want the full TMview record. There is no explicit statement about when not to use it or which alternative (e.g., tmview_search, eutm_get) to prefer, leaving the agent to infer from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[TMview search — national registers, WIPO] Einzelabfrage in TMview (tmdn.org) — nationale Register und WIPO. aemter: Amtskürzel, Standard ["AT"]; z. B. ["AT","WO"] für österreichische Marken und internationale Registrierungen, ["DE"], ["CH"]. modus: enthaelt (Wildcards * erlaubt) | exakt (ganzes Wort) | unscharf (TMview-Fuzzy) | woerter. Liefert Kurzdaten je Treffer mit ST13-Kennung für tmview_get. Für die vollständige Recherche recherche_lauf verwenden.
| Name | Required | Description | Default |
|---|---|---|---|
| modus | No | enthaelt | |
| aemter | No | ||
| klassen | No | ||
| zeichen | Yes | ||
| nur_lebend | No | ||
| max_treffer | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does explain the output shape ('Liefert Kurzdaten je Treffer mit ST13-Kennung'), the supported search modes, and the underlying source (tmdn.org). It does not mention rate limits, errors, or the read-only nature of the operation, leaving some behavioral aspects implicit.
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 dense but relatively compact, and it front-loads the core purpose before parameter details. The examples for 'aemter' and the enumeration of 'modus' modes earn their place. It is slightly run-on and mixes languages, but it stays close to the essential information.
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 six parameters, zero schema-level descriptions, and no annotations, the description is incomplete. It covers the general workflow and the two most important parameters, but leaves multiple parameters and edge-case behavior unaddressed. An agent could misinvoke it by misunderstanding 'zeichen' or 'klassen'.
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%, so the description must compensate. It explains 'aemter' and 'modus' in some detail, but the required parameter 'zeichen' is not described, and 'klassen', 'nur_lebend', and 'max_treffer' receive no semantic explanation. The parameter names hint at their meaning, but the description does not provide the needed precision for correct invocation.
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 a specific operation — 'Einzelabfrage in TMview (tmdn.org)' — and scopes it to national registers and WIPO. It also distinguishes itself from tmview_get by noting it returns short data with an ST13 identifier for later detail retrieval, and from recherche_lauf by directing full searches elsewhere.
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 gives clear context: this is a single-query TMview search for national and WIPO registers. It explicitly names recherche_lauf for the full search alternative and mentions tmview_get for subsequent detail retrieval. However, it does not explicitly exclude other siblings like eutm_search or state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[search variants] Bildet deterministisch die Suchvarianten für ein Wortzeichen (Stamm, Wildcards, Schreibweisen, Konsonantenskelett, bei umfang='breit' auch Vokaltausch). Zeigt, was recherche_lauf abfragen wird — für das Suchprotokoll und um Varianten zu ergänzen. umfang: knapp | normal | breit.
| Name | Required | Description | Default |
|---|---|---|---|
| umfang | No | normal | |
| zeichen | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It discloses deterministic behavior, enumerates the kinds of variants generated, and explains that 'umfang='breit'' additionally enables vowel swapping. It also clarifies that the tool only shows what 'recherche_lauf' will query, signaling a read/computation-oriented operation. It does not mention auth, rate limits, or side effects, but the described behavior makes these seem unnecessary.
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 compact and front-loaded with the tool category and core action. Each sentence contributes: variant generation, relation to 'recherche_lauf', and the 'umfang' parameter values. The dense technical phrasing and dashes slightly reduce readability, but there is no wasted 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 that an output schema exists, the description does not need to explain return values. It covers the tool's purpose, its role in the search workflow, its deterministic nature, and the main parameter. The main gap is the lack of explicit read-only/safety wording and any constraints on the 'zeichen' input, but for a simple variant-generation helper the description 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?
Schema description coverage is 0%, so the description must compensate for the bare schema. It gives meaning to 'zeichen' as the word token for which variants are built, and it documents the 'umfang' values 'knapp | normal | breit', including the concrete effect of 'breit'. This goes beyond the schema, which only provides a type and default. It does not fully define the boundary between 'knapp' and 'normal', but the core parameter semantics are sufficiently clarified.
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 names a concrete operation: 'Bildet deterministisch die Suchvarianten für ein Wortzeichen' and lists the variant categories it generates. It also differentiates the tool from the actual search workflow by saying it shows what 'recherche_lauf' will query, which helps separate it from search-oriented siblings. However, it does not explicitly contrast itself with the other sibling tools, so it stops short of a 5.
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 gives clear usage context: the tool is meant 'für das Suchprotokoll und um Varianten zu ergänzen' and it reveals what 'recherche_lauf' will query, implying it is a preparation/helper step before running a search. It does not state when not to use it or name alternative variants-generating tools, so the guidance is clear but not exhaustive.
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.
v0.1.0eutm_geteutm_searchmarken_statusnizza_klassenueberschriftennizza_suggestnizza_validaterecherche_lauftmview_gettmview_searchvariantenScored across 10 tools
Each tool has a clear primary purpose, but eutm_search/tmview_search and eutm_get/tmview_get differ only by data source, which could cause misselection if an agent doesn't read the descriptions carefully. The nizza_* tools are distinct and the main recherche_lauf is clearly a composite workflow.
Names use a consistent lowercase-with-underscore style, but the pattern is mixed: some are source_action (eutm_get, tmview_search), others are bare nouns (varianten, recherche_lauf, marken_status), and classification tools share the nizza_ prefix. This is readable but not as uniform as a strict verb_noun convention.
With 10 tools, the server is well-scoped for trademark search and classification. Each tool addresses a distinct part of the workflow (status, record retrieval, search, variant generation, composite search, and Nizza support) without unnecessary bloat.
The tool set covers the full word-mark clearance workflow: generating variants, searching multiple registers, retrieving full records, and validating/suggesting Nice classifications. No critical gaps are apparent for the stated domain; the main search tool returns a consolidated and scored result.
Trademark search, monitoring and conflict research across 30+ registers, with provenance.
Trademark clearance (USPTO+TMview) and self-graded stock signals for AI agents. JSON verdicts.
Search 13.7M+ USPTO trademarks. Clearance, phonetic matching, TTAB stats, analytics.
US & EU trademark, domain & handle clearance — a signed three-state verdict, not legal advice.
