get_owner_filing_trendsGet a trademark owner's filing trends over time — yearly filing counts broken down by Nice class. Shows how the owner's trademark portfolio has evolved.
| Name | Required | Description | Default |
|---|---|---|---|
| end_year | No | End year (default: current year) | |
| owner_name | Yes | Owner name as shown in USPTO records (e.g., "NIKE, INC."). Use search_by_owner first to find the exact name. | |
| start_year | No | Start year (default: 2000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds context beyond annotations by specifying that results are yearly counts broken down by Nice class and that they reflect portfolio evolution. It does not disclose any surprising behaviors, but it adds useful detail about the output granularity.
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 sentences, front-loaded with the primary purpose ('Get a trademark owner's filing trends over time'), and includes a useful secondary sentence about portfolio evolution. No redundant 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?
Given the simple read-only nature, the schema covers all parameters, and annotations cover safety, the description sufficiently conveys the output (yearly filing counts by Nice class) and its interpretive value. No output schema exists, but the description outlines the key structure of the returned data.
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 100%, so all three parameters have clear descriptions. The main description does not add any parameter-specific meaning beyond what the schema already provides. Baseline of 3 is appropriate since the schema does the heavy lifting.
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 function: retrieving a trademark owner's filing trends over time, broken down by Nice class. It uses a specific verb ('Get') and resource, and the mention of 'yearly filing counts broken down by Nice class' distinguishes it from other owner-related tools like get_owner_ai_summary or get_owner_deadlines.
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 clear context for when to use the tool ('Shows how the owner's trademark portfolio has evolved'), which implies a use case. However, it does not explicitly name alternatives or exclusion scenarios, so it falls short of a 5. The schema parameter description for owner_name does suggest using search_by_owner first, but that is outside the main description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have clearly defined scopes, but several search/count tools overlap (search_trademarks, phonetic_search, run_knockout_search, get_similar_marks) and owner/firm analytics tools have similar boundaries. Descriptions help differentiate them, but the large set increases the chance of misselection.
All tool names follow a consistent lowercase snake_case verb_noun pattern (get_, search_, run_, analyze_, etc.). The only minor deviation is web_research, which is noun_verb, but it remains perfectly readable and consistent with the overall style.
61 tools is extreme for any server, far exceeding the 50+ threshold. Even for a comprehensive trademark platform, this number overwhelms agents with selection complexity and makes the toolset difficult to navigate.
Several tools launch asynchronous processes and instruct users to call status tools (get_prosecution_history_status, get_ttab_proceeding_analysis_status, get_office_action_research_status) that are not present in the toolset. Additionally, search_trademarks and phonetic_search reference list_marks_containing_term, which is also missing. These critical gaps cause agent failures when following the described workflows.