Google Patents MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOG_LEVEL | No | Log level for the server (error, warn, info, http, verbose, debug, silly) | info |
| SERPAPI_API_KEY | Yes | Your API key from SerpApi to use the Google Patents API |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_patentsC | Searches Google Patents using SerpApi. Allows filtering by date, inventor, assignee, country, language, status, type, and sorting. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 1 tool
With only one tool, there is no possibility of ambiguity or confusion between tools. The single tool has a clear, distinct purpose focused on searching patents.
The single tool name 'search_patents' follows a consistent verb_noun pattern. Since there is only one tool, naming consistency is inherently perfect with no deviations to assess.
A single tool for a patents server feels thin and under-scoped. While search is a core function, the domain suggests potential for additional operations like retrieving patent details, analyzing trends, or filtering by categories, making the count too low for the apparent scope.
The tool surface is severely incomplete for a patents domain. It only provides search functionality, with obvious gaps such as retrieving full patent documents, getting metadata like citations or legal status, or managing saved searches, which limits agent workflows and causes dead ends.