Patent Intelligence MCP
Server Details
Patent search, USPTO data, patent landscape & pgvector prior-art search for agents.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 7 of 7 tools scored.
Each tool targets a clearly distinct purpose: portfolio overview, daily digest, patent details, prior art search, keyword search, trending technologies, and network info. No overlapping functionality.
All tool names use snake_case consistently, but they mix noun_noun (company_patents, patent_detail) and verb_noun (search_patents) patterns, lacking a strict verb_noun convention throughout.
With 7 tools, the set is well-scoped for patent intelligence research, covering search, detail, portfolio, trends, digest, and prior art without being bloated or sparse.
The tool surface covers the essential patent research workflow: searching, browsing portfolio, detailed view, daily digest, prior art, and trend analysis. No obvious gaps for the intended domain.
Available Tools
7 toolscompany_patentsAInspect
Patent portfolio for a company/assignee — total count, 90-day filing velocity, primary technology areas (CPC), and recent filings. Patent landscape + competitive IP intelligence.
PAID: $0.01 USDC per query after the daily free allowance (25/day). On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses it.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| days_back | No | optionally restrict recent filings to the last N days. | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. | |
| company_name | Yes | assignee/company name, partial match (e.g. "Qualcomm"). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description discloses the paid nature, free allowance, and payment flow on 402 errors. It also outlines output content. Missing details on rate limits or permissions, but overall informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight paragraphs: first explains function, second explains payment/auth. Front-loaded with purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters, and payment for a paid tool with output schema. Lacks details on error conditions or additional behavior, but sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description provides minimal extra beyond schema descriptions. All parameters are explained in the schema, so the description adds limited additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a patent portfolio overview for a company, including total count, filing velocity, technology areas, and recent filings. It distinguishes from siblings focused on individual patents or searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus siblings like search_patents or patent_detail. No guidance on when not to use it or which alternatives are better suited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daily_digestAInspect
Structured daily patent-filing digest — what published/granted in the last day, with top CPC classes, top assignees, and the patent list. Optionally scoped to a CPC class or an assignee.
PAID: $0.02 USDC per query after the daily free allowance (25/day). On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses it.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| assignee | No | optional assignee/company name to scope the digest. | |
| cpc_code | No | optional CPC class/subclass prefix to scope the digest. | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool returns structured digest data, details the payment model (free allowance, $0.02 per query after 25/day), and explains the 402 error workflow. However, it does not explicitly state whether the tool is read-only or if it has side effects, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the tool's core purpose in the first sentence, followed by details on optional scoping. The payment details are necessary but slightly lengthy; overall, it is well-structured and avoids redundant information. A minor improvement would be to condense the payment flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to detail return values. It covers the digest contents, optional scoping, and critical payment/error handling context. For a tool of moderate complexity, this provides sufficient information for an agent to use it effectively, though it could be more explicit about idempotency or retry behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good individual parameter descriptions. The description adds value by explaining the payment_tx parameter's role in re-calling after 402, and clarifies that the assignee and cpc_code parameters are optional for scoping. This goes beyond the schema's baseline, justifying a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a structured daily digest of patent filings including published/granted patents, top CPC classes, top assignees, and patent list. This distinguishes it from sibling tools like search_patents (focused on search) and patent_detail (focused on details), making its unique role evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for daily overviews and briefly mentions optional scoping to CPC class or assignee, but does not explicitly specify when to use this tool over alternatives like company_patents or prior_art_search. The payment and error handling instructions are provided but are more operational than comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mint_infoAInspect
FoundryNet Data Network info + MINT Protocol details. FREE.
Returns how to attest your agent's patent research with MINT Protocol for verifiable on-chain proof, the MINT MCP endpoint, and the sister data servers (gov-contracts-mcp, brand-intel-mcp).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must disclose behavior. It mentions 'FREE' and lists returned data, but fails to address idempotency, side effects, authentication, or rate limits. Adequate only for minimal risk tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with core purpose. Every sentence contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and simple read-only nature, the description fully sets expectations: what is returned (attestation method, endpoint, sister servers). Output schema exists, so no further detail needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; baseline is 4. Schema coverage is 100%, so no param info needed. Description adds value by detailing output contents, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool provides 'info + MINT Protocol details' and lists specific outputs (attestation method, endpoint, sister servers). This distinguishes it from siblings like patent search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage context (getting MINT protocol info) but lacks explicit when-to-use or when-not-to-use guidance, nor mentions alternatives. It's functional but not directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
patent_detailAInspect
Full record for a single patent — title, abstract, inventors, assignee, CPC codes, claims count, citation count, filing/grant dates. FREE.
| Name | Required | Description | Default |
|---|---|---|---|
| patent_number | Yes | the USPTO patent number from a search result. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, yet the description only mentions 'FREE' and lists return fields. It fails to disclose any behavioral traits such as rate limits, authentication requirements, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose and contents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists to describe return values, this description is fairly complete for a simple detail tool. However, it could better differentiate from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single required parameter with a clear description. The tool description adds context by referencing 'from a search result', enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the full record for a single patent, listing specific fields. This distinguishes it from sibling tools that search or list patents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a detailed patent record is needed but provides no explicit guidance on when to use this tool over alternatives like search_patents or company_patents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
prior_art_searchAInspect
Prior-art search: find patents semantically similar to a free-text invention description, using pgvector cosine similarity over patent abstract embeddings. The premium IP-research tool.
PAID: $0.02 USDC per query after the daily free allowance (25/day). On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses it.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. | |
| description | Yes | free-text description of the invention / claim to match. | |
| max_results | No | number of similar patents to return (1-50, default 10). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the paid nature, free tier limits, 402 error handling, bearer key bypass, and technical method (pgvector similarity). This is comprehensive and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with two clear sections: core function and payment details. Could be slightly more structured, but every sentence adds value and it is front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (noted in context), the description does not need to explain return values. It fully covers the tool's function, technical approach, and payment mechanism, making it complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). The description adds value by explaining the payment_tx in context (re-call after 402) and the agent_id for free-tier counter, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool finds patents semantically similar to a free-text invention description using pgvector cosine similarity. This distinct purpose differentiates it from siblings like company_patents or search_patents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the payment model (free allowance, 402 handling, bearer key) and when to use it for prior art search. It lacks explicit when-not-to-use and alternatives, but the payment details provide strong usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_patentsAInspect
Search U.S. patents (USPTO PatentsView) by keyword, assignee, CPC class, date range, or type. Patent search for IP and technology-landscape research, sorted newest-first, with title, abstract, assignee, and CPC codes.
PAID: $0.01 USDC per query after a daily free allowance (25/day). On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. Pass agent_id to scope your allowance; an Authorization: Bearer fnet_ key bypasses the paywall.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max rows (1-100, default 25). | |
| date_to | No | ISO date "YYYY-MM-DD"; grant_date on/before. | |
| keyword | No | free-text matched against title + abstract. | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| assignee | No | assignee/company name, partial match. | |
| cpc_code | No | CPC class/subclass prefix, e.g. "H04L" or "G06N". | |
| date_from | No | ISO date "YYYY-MM-DD"; grant_date on/after. | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. | |
| patent_type | No | "utility", "design", or "plant". |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: data source (USPTO), sorting, returned fields, daily free allowance (25/day), payment cost ($0.01 per query), how to handle 402 errors (pay and re-call with payment_tx), and scoping by agent_id. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs: first covers purpose and output, second covers payment/auth. Each sentence adds value, and the crucial info is front-loaded. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, 100% schema coverage, and presence of an output schema, the description covers all essential behavioral and payment details. It is complete enough for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds meaning by clarifying that keyword matches title+abstract, assignee is a partial match, cpc_code is a prefix, date filters apply to grant_date, and payment_tx is used for re-calls after 402. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches U.S. patents via USPTO PatentsView with multiple filters (keyword, assignee, CPC class, date range, type) and specifies sorting (newest-first) and returned fields (title, abstract, assignee, CPC codes). It distinguishes itself from siblings like 'prior_art_search' and 'company_patents' by being a general search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions patent search for IP and research but does not explicitly state when to use this tool over siblings like 'prior_art_search' or 'company_patents'. It does explain the payment flow and daily allowance, providing context for usage constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trending_technologyAInspect
Which technology areas are heating up — CPC classes ranked by recent patent filing volume, each with a section description and its top assignees. Technology-trend and patent-landscape signal.
PAID: $0.01 USDC per query after the daily free allowance (25/day). On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses it.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | look-back window in days (1-365, default 30). | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. | |
| min_filings | No | only include CPC classes with at least this many filings. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses payment behavior ($0.01 USDC after 25 free queries), 402 error handling (pay with Solana memo and re-call with payment_tx), and authentication bypass (Authorization: Bearer key), providing complete behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with two clear sections: main purpose and payment/error handling. It front-loads the core functionality but could be slightly more concise in the payment paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (paid tool, error handling, 4 parameters, output schema exists), the description covers purpose, parameter usage in a specific scenario (402), and free-tier limits, making it complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds value by explaining the payment flow context for payment_tx in case of 402, going beyond the schema description to clarify usage scenario.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'CPC classes ranked by recent patent filing volume' and includes 'section description and top assignees', providing a specific verb+resource that distinguishes this from sibling patent tools like search_patents or patent_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for technology trend analysis via 'Technology-trend and patent-landscape signal', but does not explicitly contrast with sibling tools or state when not to use it, though the goal is clear from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!