get_owner_goods_keywordsGet the most frequent goods/services keywords for a trademark owner. Shows what products and services the owner focuses on, useful for understanding their brand strategy and identifying class patterns.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max keywords to return | |
| owner_name | Yes | Owner name as shown in USPTO records (e.g., "NIKE, INC."). Use search_by_owner first to find the exact name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds behavioral context by noting results are 'most frequent' and that they reflect owner focus, but it does not describe the return format, how ordering works, or how frequency is computed. This adds some value but lacks richer behavioral detail.
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 core action ('Get...') and immediately followed by the value statement. Every word contributes to understanding the tool; there is no wasted content. This is an efficient, well-structured description.
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 list tool with two well-documented parameters and no output schema, the description covers the purpose and use case sufficiently. It could mention the output format or limit behavior, but given the simplicity of the tool and the rich sibling context (which clarifies its niche), it is complete enough.
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% (both owner_name and limit have descriptions). The tool description does not add significant meaning beyond the schema; it mentions the concept of owner and keywords but does not elaborate on parameter usage or relationships. Given the full schema coverage, the baseline 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 uses a specific verb ('Get') and clearly identifies the resource ('most frequent goods/services keywords for a trademark owner'). It distinguishes this from sibling owner-focused tools like get_owner_ai_summary or get_owner_filing_trends by focusing on keyword frequency. The added phrase about brand strategy and class patterns clarifies the tool's value proposition.
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 clear use case ('useful for understanding their brand strategy and identifying class patterns') but does not explicitly state when to use this tool over alternatives or mention exclusions. It implies usage context rather than giving direct guidance, so it earns an implied-usage score.
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.