Blossom Research

Count patent families

count_patents

Read-onlyIdempotent

Count patent families matching filters. Returns { count: , sample: <top 5 families for citation> }. A count is a count of families in Blossom, not of patents worldwide: one family can have a patent in thirty countries. Use for 'how many patent families ...?' questions. For 'top owners', 'filings per year' or a breakdown by type use aggregate_patents instead.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "count_patents"
  }
}

Input Schema

Name	Required	Description	Default
`term`	No	"ended" = the estimated 20-year term is over; "running" = it is not, or there is no estimate. The estimate is the filing date plus 20 years: adjustments, extensions and unpaid fees change the real date.
`limit`	No
`owner`	No	Owner of the family: an organisation name or a Blossom organisation slug ("COMPASS Pathways", "MindMed", "gh-research", "Sandoz"). A name, other name or slug of a Blossom organisation record matches the families that are linked to it. Any other name matches the owner names as printed on the publications, word by word.
`query`	No	Text search across the title, the Blossom summary, the abstract, the first claim, owner and inventor names, compounds, indications and publication numbers. For an exact publication number use publicationNumbers.
`stage`	No	"granted" = at least one office has granted a patent of the family; "application" = applications only. This is the reliable stage from the document kinds, not a check that the patent is in force.
`topics`	No	Topic slugs of the indications that the claims or the stated purpose name (e.g. "depressive-disorders", "ptsd"). Under half of the families name an indication.
`offices`	No	Offices where the family has a publication, as two-letter codes ("US", "EP", "WO" for a PCT application, "JP", "CN"). Country names are auto-mapped.
`orderBy`	No	Sort order. "relevance" = best text match (newest priority date first when there is no query). "newest" / "oldest" = by priority date. "mostCited" = families that later patents cite most.	relevance
`inventor`	No	Inventor name ("Albert Hofmann", "Nichols"). A name that identifies one Blossom person record matches the families linked to it; any other name matches the inventor names as printed, word by word.
`compounds`	No	Compound slugs that the claims are directed at (e.g. "psilocybin", "mdma", "esketamine"). Common names are auto-mapped. A family whose claims are for a new molecule often has a compound class and no compound: use compoundClasses for those.
`priorityTo`	No	Inclusive upper bound of the priority date (YYYY-MM-DD).
`patentTypes`	No	What the claims cover: "derivative" (a new compound, salt, crystal form or prodrug), "delivery-formulation", "method-of-treatment", "method-of-manufacture", "drug-combination", "other".
`priorityFrom`	No	Inclusive lower bound of the priority date (YYYY-MM-DD). The priority date is the date that orders inventions; a family with no priority date in the source is not in a dated result.
`grantedOffices`	No	Offices that granted a patent of the family ("US", "EP", ...).
`compoundClasses`	No	Chemical family of what is claimed: "tryptamine" (psilocybin, DMT, 5-MeO-DMT and analogues), "lysergamide" (LSD type), "phenethylamine" (mescaline, 2C family), "entactogen" (MDMA type), "arylcyclohexylamine" (ketamine family), "iboga-type", "other". "general" = claims that are about no single compound (any psychedelic, a tool or a device).
`publicationNumbers`	No	Publication or patent numbers, in any usual form ("US 10,519,175 B2", "US10519175B2", "WO2019073379A1", "EP3927338"). Each number matches the family that has it as a member. A number with no kind code matches every kind.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds a genuinely valuable semantic caveat (a count is families in Blossom, and one family can span thirty countries) and the sample-of-5-for-citation detail. Beyond that it does not add behavioral context such as whether filters combine with AND or what happens with zero matches, so it sits above baseline but not high.

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?

Three tight sentences, front-loaded with purpose, then the counting caveat, then routing to the sibling. Every sentence earns its place, though the literal return-shape sentence partly restates the output schema that already exists; that is the only slight redundancy.

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 16-parameter, all-optional filtered count tool with an output schema and full annotations, the description covers purpose, counting semantics and sibling routing adequately. Minor gaps remain — no statement that filters combine conjunctively or about empty-result behavior — but nothing critical for correct invocation is missing.

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

Parameters3/5

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

Schema description coverage is 94%, so nearly every one of the 16 filters is already documented at the schema level, including term, stage, priority dates and the compound/class distinction. The description itself adds no parameter-specific meaning beyond the generic phrase "matching filters"; the family-versus-patent caveat is about result semantics rather than any parameter. Baseline 3 is appropriate.

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 ("Count patent families matching filters") and immediately defines what is being counted — families in Blossom, not patents worldwide — which is the key disambiguation an agent needs. It also names the sibling aggregate_patents so the tool is distinguishable without opening any 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?

Gives an explicit positive trigger ("Use for 'how many patent families ...?' questions") and an explicit exclusion with the alternative to use instead ("top owners", "filings per year", breakdown by type → aggregate_patents). Nothing is left to inference about when this tool is the wrong choice.

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

All Blossom Research tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?