GleanMark Trademark Search

Top Trademark Filers

get_top_filers

Read-only

Get a ranked filer table for a date range, filer type, and optional Nice classes. Use this when the user asks for top filers, top owners, top law firms, or top correspondents by class or date, such as "Who are the top 10 filers in Class 9 in 2025?" Returns the ranked rows with per-filer live, registered, and pending counts plus corpus totals. 🔥 ONE CALL. Ask for everything you need in a SINGLE call by setting limit (up to 100) and the full date range, including multi-year. Do NOT make several calls to assemble one list: the windows overlap, each call renders its own table, and the answer ends up showing the same firms two or three times. Use offset ONLY to reach past rank 100, or to fetch one specific band the user named (ranks 40-45 is limit: 6, offset: 39).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of ranked filers to return. Up to 100 in a single call.
`offset`	No	Rank to start from, 0-based. Use with limit to reach deeper bands: ranks 40-45 are limit 6, offset 39. Ranks in the response already account for this.
`rank_by`	No	What to order by. 'filings' is raw volume and is dominated by high-volume online filing services. 'success_rate' ranks by registrations as a share of DECIDED outcomes (registered vs abandoned), which surfaces quality rather than throughput. Every response carries success_rate_percent and supplemental_percent regardless of ordering.	filings
`end_date`	Yes	Inclusive end date in YYYY-MM-DD format.
`filer_type`	No	Whether to rank owners, law firms, or individual correspondents.	owner
`start_date`	Yes	Inclusive start date in YYYY-MM-DD format.
`min_filings`	No	Minimum filings a filer needs to appear. Defaults to 25 when rank_by is success_rate, 0 otherwise. Required for rate rankings: without a floor a filer with 2 marks and 2 registrations scores 100% and outranks a firm that won 900 of 1,000.
`nice_classes`	No	Optional Nice classes to filter by. Use integers like 42 or 9.
`filer_profile`	No	Restrict to a kind of filer. Firm rankings only. 'filing_service' is a curated, human-verified list of productized high-volume filing operations (LegalZoom, Rocket Lawyer, Swyft and similar) — use 'law_firm' to EXCLUDE them, which is what a user means by "exclude the agencies/factories". 'full_service' is a law firm that litigates (files TTAB oppositions/cancellations); 'prosecution_only' is a law firm that mostly does not — that is practice scope, NOT a judgment about quality, and prosecution-only firms are entirely legitimate. 'in_house' is a company's own trademark department (Mattel, Disney), not a firm serving clients.	all

Output Schema

TableJSON Schema

Name	Required	Description	Default
`title`	Yes
`summary`	Yes
`end_date`	Yes
`headline`	Yes
`returned`	Yes
`filer_type`	Yes
`start_date`	Yes
`leader_name`	No
`nice_classes`	Yes
`presentation`	Yes
`leader_detail_url`	No
`leader_filing_count`	Yes
`total_matching_filers`	Yes
`total_matching_filings`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnlyHint and destructiveHint annotations, the description discloses the overlapping-window behavior and why multiple calls produce duplicate firms across tables. It also explains that each response carries live, registered, and pending counts plus corpus totals, which is valuable behavioral context for an agent composing answers.

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?

The description is front-loaded with the core purpose and use case, then adds focused operational guidance. It is slightly repetitive in the 'ONE CALL' paragraph, where 'SINGLE call' and 'Do NOT make several calls' restate the same point, but the content is dense and earns its place overall.

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

Completeness5/5

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

With a full output schema, complete parameter descriptions, and safety annotations, the description covers the remaining contextual essentials: what the returned rows contain, when to use the tool, and the critical single-call/offset behavior. Nothing an agent needs to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so parameters are fully documented in the schema already. The description adds important semantic guidance for limit and offset—specifically the 'ONE CALL' instruction, the only-100-per-call rule, and the rank-band offset example—which goes beyond the schema's baseline.

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?

The description opens with a specific verb and resource: 'Get a ranked filer table for a date range, filer type, and optional Nice classes.' It explicitly maps to user intents like top filers, top owners, top law firms, and top correspondents, which separates it from the many sibling retrieval tools.

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

Usage Guidelines4/5

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

It clearly states when to use the tool: 'Use this when the user asks for top filers, top owners, top law firms, or top correspondents by class or date.' It also gives strong negative guidance about not making multiple calls and using offset only for deep or requested rank bands. It does not name a specific sibling alternative, but the trigger conditions are unambiguous.

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

All GleanMark Trademark Search tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.4/5.0

Disambiguation3/5

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.

Naming Consistency5/5

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.

Tool Count1/5

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.

Completeness2/5

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.

Resources

Need Help?