Skip to main content
Glama
riemannzeta

USPTO Patent MCP Server

by riemannzeta
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_cpc_info

Read-onlyIdempotent

Look up any CPC patent classification symbol to get its title, hierarchy, and subgroups for reading patents or selecting codes for search.

Instructions

Look up a CPC (Cooperative Patent Classification) symbol at any depth.

USE THIS TOOL WHEN: You need the title of a CPC code — section (G),
class (G06), subclass (G06N), main group (G06N 3/00) or subgroup
(G06N 3/08) — its place in the hierarchy, or the groups beneath it,
whether reading the codes on a patent or choosing codes for a
`.cpc.` search.

Sections and classes come from a bundled table. Subclasses and groups
come from USPTO's published CPC scheme page for the subclass (one
fetch per subclass per day, no key), so titles track the current CPC
version.

Args:
    cpc_code: Any CPC symbol form: "G06N3/08", "G06N 3/08",
           "H04B7/0417 20130101" (as PPUBS prints it), "G06N", "G06",
           "G".

Returns:
    Section: title, description and its classes. Class: section and
    class titles. Subclass or group: `title`, `level`, `hierarchy`
    from the subclass down to the code, direct `children`, and the
    source page. If the scheme page cannot be fetched, the static
    section and class titles come back with a `scheme_error`.

Input Schema

NameRequiredDescriptionDefault
cpc_codeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.8.1
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "additionalProperties": true,
-      "title": "Result",
-      "type": "object"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "get_cpc_infoOutput",
-  "type": "object"
-}New value: +null
  2. First observedv1.1.1

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent/openWorld annotations by disclosing the data provenance split (bundled table for sections/classes vs. USPTO scheme page for subclasses/groups), the fetch cost ('one fetch per subclass per day, no key'), and the degradation path ('scheme_error' fallback to static titles). That is exactly the operational context an agent cannot infer from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the one-line purpose, then organizes the rest into labeled WHEN and Args/Returns blocks so an agent can skim. Length is justified by the accepted-input variety and the branchy return shape; no sentence is filler.

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 no output schema, the description supplies the return contract at every depth (section title/description/classes; class titles; subclass/group title, level, hierarchy, direct children, source page) plus the partial-failure case. For a 1-parameter tool this leaves nothing an agent needs missing.

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

Parameters5/5

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

Schema coverage is 0% — the single parameter has no description — so the description carries the full burden and does so thoroughly, enumerating accepted forms: compact ('G06N3/08'), spaced ('G06N 3/08'), PPUBS-style with date ('H04B7/0417 20130101'), and bare hierarchy prefixes ('G06N', 'G06', 'G'). This is meaning the schema does not supply.

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 (look up) and resource (a CPC symbol) with the exact depths supported (section, class, subclass, main group, subgroup) and explicitly what it returns at each depth. No sibling tool covers CPC classification, so the agent can rule out the rest of the list immediately.

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 'USE THIS TOOL WHEN' block gives concrete triggering contexts — reading CPC codes off a patent or selecting codes for a `.cpc.` search — which is clear positive guidance. It stops short of naming an alternative or stating when not to use it, but that is largely because no sibling does CPC lookup.

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

Deploy Server

Other Tools