Skip to main content
Glama
deeparchi-ai

Patent MCP Server

by deeparchi-ai

get_patent_claims

Retrieve patent claims text by publication number to determine the legal scope of protection. Supports US, CN, and other countries through Google Patents.

Instructions

Get patent claims text by publication number. Claims define the legal scope of patent protection. Supports US, CN, and most other countries via Google Patents.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
publication_numberYesPatent publication number, e.g. 'US-7650331-B1', 'CN-103257828-A'

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.9.2

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description must carry the full burden, and it does disclose useful behavioral context: data coverage across US, CN, and most other countries via Google Patents. It does not mention return format beyond 'text', rate limits, or failure behavior for unknown publication numbers, so a mid score is warranted.

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 short sentences, front-loaded with the action, and nothing is redundant. The middle sentence is slightly educational but earns its place by justifying why an agent would fetch claims.

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 simple one-parameter retrieval tool with no output schema, the description covers what it fetches, the identifier to use, and country coverage. It is close to sufficient, with only minor gaps around return format and error behavior.

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?

There is a single required parameter with 100% schema coverage and concrete example formats ('US-7650331-B1', 'CN-103257828-A'), so the schema does the heavy lifting. The description only restates 'by publication number' and adds no format or parsing detail beyond that.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (get patent claims text) and keys off a publication number, which clearly separates it from siblings like get_patent, get_legal_status, or search_patents. It could be sharper by explicitly noting it returns claims only rather than the full patent, but the resource is unambiguous.

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

Usage Guidelines3/5

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

Usage is implied ('Claims define the legal scope of patent protection') which hints at when an agent should want claims rather than a full patent, but it names no alternative tools or explicit when-not conditions. No routing guidance is given despite several closely related siblings.

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