Skip to main content
Glama

Govparse Government Data Gateway

by io.govparse

uspto_assignees_search

Which companies are new to patenting, and in what technology? Search patent assignee ORGANIZATIONS (entity-resolved), each with first/last grant date, patent count, distinct CPC subclasses, and inventor count. new_assignee=true isolates orgs with their first-ever US patent grant (emerging/stealth signal for VC deal sourcing and corp-dev); narrow by CPC subclass, state/country, first-grant window, or patent_count_min. PatentsView grants (CC BY 4.0), observational. [price: $0.05/row]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNofield:direction — patent_count | first_grant_date | last_grant_date. Default 'last_grant_date:desc'.
limitNoMax rows (default 25, cap 100).
stateNoAssignee state code(s), CSV.
offsetNoRows to skip, for paging.
countryNoAssignee country code(s), CSV (ISO).
assigneeNoAssignee organization (company) name fragment.
cpc_subclassNoCPC subclass/class/section the org patents in, CSV. G06N=AI/ML.
new_assigneeNotrue → only new/emerging assignees (first-ever patent grant recent).
assignee_entityNoResolved entities.employers entity_id (UUID), exact match.
patent_count_maxNoMaximum granted-patent count held by the org (lifetime total).
patent_count_minNoMinimum granted-patent count held by the org (lifetime total).
pct_increase_minNoMinimum percent increase, recent window vs prior window (100 = the count doubled) — the real patent-surge threshold.
first_grant_afterNoOrg's first observed grant on or after (YYYY-MM-DD).
first_grant_beforeNoOrg's first observed grant on or before (YYYY-MM-DD).
prior_patent_count_minNoMinimum granted-patent count in the PRIOR comparison window (floors out noise on pct_increase_min).

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed4 schema fields changed
    • changedInput schema / properties / patent_count_max / description
      Previous value: -"Maximum granted-patent count held by the org."New value: +"Maximum granted-patent count held by the org (lifetime total)."
    • changedInput schema / properties / patent_count_min / description
      Previous value: -"Minimum granted-patent count held by the org."New value: +"Minimum granted-patent count held by the org (lifetime total)."
    • addedInput schema / properties / pct_increase_min
      Added value: +{
+  "description": "Minimum percent increase, recent window vs prior window (100 = the count doubled) — the real patent-surge threshold.",
+  "examples": [
+    100
+  ],
+  "type": "number"
+}
    • addedInput schema / properties / prior_patent_count_min
      Added value: +{
+  "description": "Minimum granted-patent count in the PRIOR comparison window (floors out noise on pct_increase_min).",
+  "examples": [
+    2
+  ],
+  "type": "integer"
+}
  2. Added

TDQS

A4.1/5.0
Behavior3/5

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

No annotations are provided, so the description carries full behavioral burden. It does disclose the data source (PatentsView grants, CC BY 4.0), observational nature, and per-row pricing ($0.05/row). However, it omits behavioral details like pagination limits, response shape, rate limits, or sorting behavior beyond the schema, leaving some transparency gaps.

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 a dense three-sentence paragraph that front-loads the core value proposition. It introduces filters, use case, and data provenance efficiently. Slightly long for a single block with multiple parentheticals, but each clause earns its place; a bulleted structure would improve scannability slightly.

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?

With 15 parameters, no output schema, and no annotations, the description compensates well by explaining the tool's purpose, filtering logic, use case, and data source. The low-level intra-parameter semantics (e.g., first_grant date meaning) are partially covered. Given the tool's complexity and lack of structured support, it does a solid job though it could clarify return ordering and pagination.

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%, which sets a baseline of 3. The description adds meaning beyond the schema by explaining new_assignee's semantics ('first-ever US patent grant'), clarifying pct_increase_min as 'the real patent-surge threshold' and its doubling semantics, and contextualizing cpc_subclass (G06N=AI/ML). This exceeds the 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 clearly states a specific verb+resource: 'Search patent assignee ORGANIZATIONS (entity-resolved)' with concrete output fields (first/last grant date, patent count, CPC subclasses, inventor count). It distinguishes itself from siblings by focusing on entity-resolved assignee organizations and mentioning the new_assignee 'emerging/stealth signal' use case.

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?

The description names concrete filter dimensions (CPC subclass, state/country, first-grant window, patent_count_min) and orients toward VC deal sourcing and corp-dev use cases. However, it does not explicitly name alternatives or state when to prefer sibling tools like uspto_patents_search or uspto_feed_grants over this one.

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

All Govparse Government Data Gateway toolsInspect
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

A4.2/5.0
Disambiguation5/5

Each tool targets a distinct domain and specific action (e.g., FDA approvals vs clearances vs recalls; firmstanding business360 dossier vs search vs screen). Even overlapping concepts like 'business360' vs 'business360_lookup' are distinguished by input (UUID vs name+state). No two tools appear to do the same thing.

Naming Consistency5/5

All tools use a consistent lowercase snake_case pattern with domain prefix (e.g., fda_*, firmstanding_*, fmcsa_*, govcon_*). Action words (search, lookup, screen, feed, stats) follow predictable usage. The naming is uniform and easy to parse.

Tool Count4/5

38 tools is on the higher end but appropriate for a comprehensive government data gateway spanning multiple agencies and datasets. Each domain has a reasonable number of tools (e.g., FMCSA: 7, OFLC: 6). Could potentially be trimmed slightly, but overall well-scoped for the stated purpose.

Completeness5/5

The tool surface covers the major government data sources comprehensively: FDA (approvals, clearances, recalls), FMCSA (carrier census, safety, insurance, etc.), FSIS, DOJ/OFLC, OSHA/EPA/DOL enforcement, SEC insider filings, clinical trials, VA facilities/opportunities/vendors, and federal contracting. No obvious gaps for the stated gateway purpose.

Resources