USPTO Patent MCP Server

tm_search_trademarks

Read-onlyIdempotent

Search US federal trademark applications and registrations by mark text, owner, goods/services, or international class. Supports clearance searches, portfolio mapping, and status filtering for live or dead marks.

Instructions

Search US federal trademark applications and registrations.

USE THIS TOOL WHEN: You need to find trademarks by mark text, owner,
goods/services description, or Nice/international class — e.g.
clearance/knockout searches for a proposed mark, or mapping a company's
trademark portfolio.

NOTE: Backed by the undocumented internal API behind tmsearch.uspto.gov
(the TESS replacement) — same risk profile as PPUBS; may break without
notice. For authoritative status of a specific mark, use
tsdr_get_trademark_status. Federal marks only (no common-law/state marks).

Args:
    query: Raw query string for advanced searches
    mark_text: Word mark text to search (e.g., "ACME")
    owner_name: Owner/applicant name to search
    goods_services: Goods/services description terms (e.g., "athletic
        footwear") — useful for clearance searches across wording
    registration_number: Exact registration number to look up
    international_class: Nice class number 1-45 (e.g., "9" for software;
        use get_trademark_class_info to look up classes)
    status_filter: "live" (active marks), "dead" (abandoned/cancelled/
        expired), or omit for both
    offset: Starting position for pagination (default: 0)
    limit: Maximum results to return (default: 25, max: 100)

Returns:
    Normalized response with matching trademark records.

Input Schema

Name	Required	Description	Default
`limit`	No
`query`	No
`offset`	No
`mark_text`	No
`owner_name`	No
`status_filter`	No
`goods_services`	No
`international_class`	No
`registration_number`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.8.1Oct 17, 2026

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "result": {
-      "additionalProperties": true,
-      "title": "Result",
-      "type": "object"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "tm_search_trademarksOutput",
-  "type": "object"
-}New value: +null

First observedv1.1.1Aug 19, 2026

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description goes further with genuinely non-obvious context: the backend is an undocumented internal API behind tmsearch.uspto.gov with real risk of breaking without notice, plus the federal-only scope boundary. It stops short of disclosing pagination behavior or rate limits, so not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose, then routes with a labeled WHEN block, a NOTE on risk, and a Args list where every line earns its place. The Args section is repetitive in prefixing each name, but the content is dense rather than padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter search tool with no output schema, all inputs are documented and alternatives are named. The Returns block is thin ('Normalized response with matching trademark records') and says nothing about pagination semantics or result shape, which is the one meaningful gap since no output schema exists to compensate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden and does it well: every one of the 9 parameters is explained with meaning and examples (mark_text "ACME", international_class 1-45 with "9" for software, status_filter's live/dead/omit values). It adds value the schema cannot, such as 'athletic footwear' being useful for clearance searches across wording, and limit's default 25 / max 100.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Search US federal trademark applications and registrations') and immediately scopes it to federal marks only. This clearly separates it from tsdr_get_trademark_status (authoritative single-mark status) and tm_get_trademark without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'USE THIS TOOL WHEN' block names concrete scenarios (clearance/knockout searches, portfolio mapping) and routes the agent elsewhere for the authoritative-status case ('use tsdr_get_trademark_status') and for class lookup ('use get_trademark_class_info'). It also states an exclusion: no common-law or state marks, only federal.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

tm_search_trademarks

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools