PatSnap MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose focused on different patent analytics dimensions: citation analysis, litigation risk, trends, valuation, legal status, assignees, origins, inventors, keyword hierarchy, and keyword frequency. There is no functional overlap between tools, making selection unambiguous for an agent.
Naming Consistency5/5
All tools follow a consistent 'get_' prefix with descriptive snake_case names (e.g., get_most_cited_patents, get_top_assignees). This uniform pattern makes the tool set predictable and easy to navigate.
Tool Count5/5
With 10 tools, the server provides a well-scoped set for patent analytics, covering key aspects like trends, risks, players, and keyword analysis. Each tool serves a unique purpose without redundancy, making the count appropriate for the domain.
Completeness4/5
The tool set comprehensively covers analytical queries for patent data, including trends, risks, valuations, and key entities. A minor gap exists in direct patent retrieval or detailed patent-level operations (e.g., get_patent_by_id), but the provided tools support robust analysis workflows.
Average 3.7/5 across 10 of 10 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions that 'IPC is prioritized by the API' when both keywords and IPC are provided, which adds useful behavioral context. However, it doesn't describe what the analysis returns (e.g., time series data, charts, statistics), whether there are rate limits, authentication requirements, or what happens with missing parameters. For a 7-parameter analytical tool with no annotation coverage, this is insufficient.
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 appropriately concise with three sentences that each serve a purpose: stating the tool's function, elaborating on the analysis scope, and specifying parameter requirements. It's front-loaded with the core purpose and avoids unnecessary repetition. However, the second sentence could be slightly more direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a 7-parameter analytical tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (trend data format, visualization, statistical summary), doesn't mention any limitations or constraints, and provides minimal behavioral context. For a tool that presumably returns complex analytical results, this leaves significant gaps for an AI agent.
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?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds minimal value beyond the schema by emphasizing the 'either keywords or IPC' requirement and the IPC prioritization rule. It doesn't provide additional semantic context about how the analysis works or what the parameters mean in the context of trend analysis, so the baseline 3 is appropriate.
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?
The description clearly states the tool's purpose: 'Analyze annual application and issued trends for patents' with a specific focus on 'trends related to specific technology fields or keywords.' It uses a clear verb ('Analyze') and resource ('patents'), but doesn't explicitly differentiate from siblings like 'get_most_cited_patents' or 'get_top_assignees' which focus on different aspects of patent data.
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?
The description provides some usage context by stating 'Either keywords or IPC classification must be specified,' which helps understand when to use this tool versus a generic search. However, it doesn't explicitly contrast with sibling tools or provide guidance on when to choose this trend analysis tool over alternatives like 'get_word_cloud' or 'get_wheel_of_innovation' for similar analytical purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context beyond basic functionality: it explains that higher value buckets indicate more lucrative technologies, design patents are excluded, and search logic prioritizes IPC over keywords. However, it lacks details on rate limits, authentication needs, error handling, or what the output looks like (e.g., distribution format), which are important for a tool with 7 parameters and no output schema.
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 appropriately sized (three sentences) and front-loaded with the core purpose. Each sentence adds value: the first states the purpose and key insight, the second adds exclusions, and the third provides critical search logic. There's no wasted text, though it could be slightly more structured (e.g., bullet points for constraints).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no annotations, no output schema), the description is moderately complete. It covers purpose, usage guidelines, and key behavioral traits, but lacks output details (what the valuation distribution looks like), error conditions, or performance characteristics. With no output schema, the agent must infer return values from the description alone, which is insufficient for full understanding.
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?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds minimal parameter semantics beyond the schema: it reinforces that 'keywords' or 'ipc' are required for a meaningful search and clarifies IPC prioritization, but doesn't provide additional meaning for parameters like date ranges or authority. Baseline 3 is appropriate as the schema does the heavy lifting.
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?
The description clearly states the tool's purpose: 'Assess the lucrativeness of a technology space based on the spread of estimated patent valuation (simple families).' It specifies the verb ('assess'), resource ('technology space'), and key metric ('spread of estimated patent valuation'), distinguishing it from siblings focused on citations, litigation, trends, etc. However, it doesn't explicitly contrast with all siblings (e.g., 'get_wheel_of_innovation' might overlap in assessing technology spaces).
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 provides clear context for usage: 'Higher value buckets indicate more lucrative technologies. Design patents are excluded. Note: Search must contain either keywords or IPC. If both are provided, IPC is prioritized.' This gives explicit guidance on when to use (for assessing lucrativeness via patent valuation spread) and constraints (excludes design patents, requires keywords or IPC). It doesn't specify when NOT to use or name alternatives among siblings, but the context is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the core function (returning top authorities) and a key constraint (keywords or IPC required), but doesn't mention other important behaviors like whether this is a read-only operation, potential rate limits, authentication requirements, or what format the results will be in. The description adds some context but leaves significant behavioral aspects unspecified.
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 appropriately concise with two sentences that each serve a clear purpose. The first sentence states the tool's purpose, and the second provides critical usage guidance. There's no wasted language, and the most important information (the requirement for keywords or IPC) is appropriately positioned. It could be slightly more structured but is efficiently written.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no annotations, and no output schema, the description provides basic but incomplete context. It covers the purpose and a key requirement, but doesn't address what the output looks like (format, structure, what 'top' means quantitatively), nor does it provide guidance on interpreting results or potential limitations. Given the complexity and lack of structured behavioral information, the description should do more to compensate.
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?
Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds minimal value beyond the schema - it mentions that 'Either keywords or IPC classification must be specified' which is also stated in the schema's description field. No additional parameter semantics or usage nuances are provided in the description beyond what's already in the structured schema.
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?
The description clearly states the tool's purpose: 'Returns the top authorities (priority countries) of origin for patents matching the criteria.' It specifies the verb ('Returns'), resource ('top authorities of origin'), and scope ('for patents matching criteria'). However, it doesn't explicitly differentiate from sibling tools like 'get_top_assignees' or 'get_top_inventors' which also return top-ranked patent data but for different entities.
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 provides clear usage context: 'Analyze main sources of priority filings' and specifies a key requirement: 'Either keywords or IPC classification must be specified.' This gives guidance on when to use the tool (for analyzing priority country sources) and what's needed for meaningful results. However, it doesn't explicitly state when NOT to use it or mention alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals important behavioral traits: returns up to 10 results, requires either keywords or IPC input, and IPC prioritization when both are provided. However, it doesn't disclose other critical behaviors like whether this is a read-only operation, potential rate limits, authentication requirements, or what specific metrics determine 'top' inventors.
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 appropriately sized with three sentences that each earn their place: purpose statement, use cases, and critical search constraints. It's front-loaded with the core purpose. There's minimal waste, though the second sentence could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters with full schema coverage but no annotations and no output schema, the description provides adequate but incomplete context. It explains the purpose and key constraints well, but doesn't address what the output looks like (beyond 'top 10 inventors'), how 'top' is determined, or other behavioral aspects that would be helpful for an agent invoking this tool.
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?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds some value by explaining the mandatory requirement of either keywords or IPC and their prioritization logic, but doesn't provide additional parameter semantics beyond what the schema already specifies. The baseline of 3 is appropriate when the schema does the heavy lifting.
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?
The description clearly states the tool's purpose: 'Shows the top inventors in the technology field' with specific verbs ('shows', 'evaluate', 'identify') and resource ('inventors'). It distinguishes from siblings like get_top_assignees by focusing on inventors rather than assignees or other patent metrics. However, it doesn't explicitly differentiate from all siblings in the list.
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 provides clear context for when to use this tool: 'Evaluate top performers or identify potential recruits' in technology fields. It also specifies a key constraint: 'Search must contain either keywords or IPC' and prioritization rules. However, it doesn't explicitly mention when NOT to use it or name alternative tools for different needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about the data source ('most recent 5,000 publications') and the requirement for keywords or IPC. However, it doesn't disclose important behavioral traits like whether this is a read-only operation, potential rate limits, authentication needs, error conditions, or what the hierarchical view output looks like. For a tool with 8 parameters and no output schema, this leaves significant 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 appropriately sized with three sentences that each earn their place: first states the purpose, second adds data source context, third provides critical usage constraint. It's front-loaded with the core functionality. There's no wasted text, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no output schema, no annotations), the description is moderately complete. It covers purpose, data scope, and a key constraint, but lacks details about output format, behavioral characteristics, and differentiation from siblings. Without annotations or output schema, the agent would need to infer or test these aspects, making this description adequate but with clear gaps for effective tool selection and invocation.
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?
Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly with examples and logic. The description adds minimal value beyond the schema: it emphasizes that 'either keywords or IPC classification must be specified' and mentions IPC prioritization when both are provided. This provides some semantic clarification but doesn't add significant meaning beyond what's in the well-documented schema.
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?
The description clearly states the tool 'provides a two-tiered hierarchical view of keywords/phrases in a technology space' and 'identifies common terms and their associations', which specifies the verb (provides/identifies) and resource (keywords/phrases in technology space). It distinguishes from siblings by focusing on hierarchical keyword analysis rather than citation counts, litigation, trends, or other patent metrics. However, it doesn't explicitly contrast with 'get_word_cloud' which might be a closer sibling.
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 provides clear context for when to use this tool: 'Based on the most recent 5,000 publications' and 'Either keywords or IPC classification must be specified.' This gives practical constraints and prerequisites. However, it doesn't explicitly state when NOT to use it or name alternatives among the sibling tools (e.g., when to choose this over 'get_word_cloud' or 'get_patent_trends').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about the search requirement (keywords or IPC) and prioritization rule, but does not cover other behavioral aspects such as rate limits, authentication needs, or what happens with invalid inputs. The description does not contradict any annotations.
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 appropriately sized with two sentences that are front-loaded with key information (purpose and constraints). Every sentence earns its place by clarifying the tool's function and usage rules without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (7 parameters, no output schema, no annotations), the description is adequate but has gaps. It explains the search requirement and result limit, but does not detail the return format (e.g., what fields are included in the top patents) or error handling, which could be important for an AI agent.
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?
The schema description coverage is 100%, providing detailed descriptions for all 7 parameters. The description adds minimal value beyond the schema by reiterating the requirement for 'keywords or IPC' and IPC prioritization, which is already covered in the schema's description. This meets the baseline for high schema coverage.
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 the tool's purpose with specific verbs ('view', 'returns') and resources ('top patents cited most frequently'), distinguishing it from siblings like 'get_most_litigated_patents' or 'get_patent_trends' by focusing on citation-based influence rather than litigation or trends.
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 provides clear context for usage by specifying that it returns 'at most Top 10 patents' and requires 'either keywords or IPC' for a meaningful search, with IPC prioritized if both are provided. However, it does not explicitly state when to use this tool versus alternatives like 'get_top_assignees' or 'get_word_cloud'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: the tool returns Top 10 results by litigation count, and has specific parameter prioritization logic (IPC over keywords). However, it doesn't mention important aspects like whether this is a read-only operation, potential rate limits, authentication requirements, or what the output format looks like (beyond 'Top 10 patents').
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?
The description is perfectly concise and well-structured: three sentences that each earn their place. The first states the purpose and output, the second explains the risk indication value, and the third provides crucial parameter guidance. No wasted words, and the most important information (purpose and parameter requirements) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no annotations, and no output schema, the description provides adequate but incomplete context. It covers the core purpose and parameter requirements well, but doesn't address the output format details (what fields are returned, structure), authentication needs, or error conditions. For a tool with this complexity and no structured output documentation, more completeness would be helpful.
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?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds some value by explaining the 'either keywords or IPC' requirement and prioritization rule, but doesn't provide additional parameter semantics beyond what's in the schema. This meets the baseline expectation when schema coverage is high.
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 the tool's purpose: 'Identify the patents involved in the most litigation cases, indicating potential risk in a technology space. Returns the Top 10 patents by litigation count.' It specifies the exact action (identify), resource (patents), scope (most litigated), and output format (Top 10 by count), distinguishing it from siblings like get_most_cited_patents or get_patent_trends.
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 provides explicit guidance on when to use this tool: 'Search must contain either keywords or IPC. If both are provided, IPC is prioritized.' This gives clear context for parameter requirements. However, it doesn't explicitly state when to choose this tool over alternatives like get_most_cited_patents or get_patent_trends, which would be needed for a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the search prioritization logic (IPC over keywords) which is valuable behavioral context. However, it doesn't mention rate limits, authentication requirements, response format, pagination, or potential side effects. The description adds some value but leaves significant behavioral aspects unspecified.
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?
The description is perfectly concise with three focused sentences: purpose statement, outcome explanation, and critical usage rule. Every sentence earns its place, and the most important information (the IPC/keywords requirement) is appropriately positioned at the end for emphasis.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no annotations and no output schema, the description provides adequate but incomplete context. It covers the core purpose and a critical usage rule, but doesn't explain what the 'breakdown' output looks like, how proportions are calculated, or what happens with the various date/authority filters. The description is minimally viable but has clear gaps.
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?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds minimal parameter semantics beyond the schema - it only reinforces the 'keywords or IPC' requirement and prioritization rule that's already in the schema description. Baseline 3 is appropriate when the schema does the heavy lifting.
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 the tool's purpose with specific verbs ('Provides a breakdown', 'Understand the proportion') and resources ('simple legal status for patents in the technology field'). It distinguishes itself from siblings by focusing on legal status distribution rather than citations, litigation, trends, or other patent metrics.
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 provides clear context about when to use this tool ('for patents in the technology field') and includes an important usage rule ('Search must contain either keywords or IPC. If both are provided, IPC is prioritized'). However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: scope limitation (most recent 5,000 patents), output limit (up to 100 keywords), and requirement for either keywords or IPC. However, it doesn't mention rate limits, authentication needs, error conditions, or what happens when neither parameter is provided. The description adds value but lacks comprehensive behavioral context.
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?
The description is perfectly concise with three sentences that each earn their place: first states purpose and scope, second explains usage context, third specifies parameter requirements. No wasted words, well-structured, and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters with full schema coverage but no annotations and no output schema, the description provides adequate but incomplete context. It covers the tool's purpose, scope, and parameter requirements well, but lacks information about return format, error handling, or performance characteristics that would be helpful for an agent invoking this tool.
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?
Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds minimal parameter semantics beyond the schema - it only reinforces that 'Either keywords or IPC classification must be specified' and mentions the 5,000 patent scope. This meets the baseline 3 when schema does the heavy lifting.
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 the tool's purpose: 'Obtain a snapshot of frequently occurring keywords/phrases from the most recent 5,000 published patents' with specific scope (5,000 patents) and output (up to 100 keywords). It distinguishes from siblings by focusing on keyword analysis rather than citation counts, litigation data, trends, or other patent metrics.
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 provides clear context for when to use this tool: 'Identify common terms for refining searches.' It specifies that either keywords or IPC classification must be specified, which is crucial guidance. However, it doesn't explicitly contrast when to use this versus alternatives like get_patent_trends or get_most_cited_patents for different analytical needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses the return limit ('Returns up to the top 10 assignees') and search prioritization behavior ('IPC is prioritized'). However, it doesn't mention rate limits, authentication needs, or error handling, leaving some gaps for a tool with 8 parameters.
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?
The description is front-loaded with the core purpose, followed by usage context and critical constraints. Every sentence earns its place: the first states what it does, the second provides usage guidance, and the third specifies key behavioral rules, with no wasted words.
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?
Given the tool's complexity (8 parameters, no output schema, no annotations), the description is reasonably complete: it explains purpose, usage, key constraints, and return limits. However, without annotations or output schema, it could benefit from more detail on response format or error cases, but it covers essential context well.
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?
Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds minimal parameter semantics beyond the schema, only reinforcing the keywords/IPC requirement and prioritization rule. This meets the baseline of 3 when schema coverage is high.
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 the tool's purpose: 'Shows the top companies (assignees) with the largest patent portfolios' and 'Returns up to the top 10 assignees.' It specifies the verb ('Shows'), resource ('top companies/assignees'), and scope ('largest patent portfolios'), distinguishing it from siblings like get_top_inventors or get_most_cited_patents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Identify largest players and competitive threats' indicates when to use it, and 'Note: Search must contain either keywords or IPC. If both are provided, IPC is prioritized' specifies prerequisites and prioritization rules, helping differentiate from other patent analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![patsnap-mcp MCP server](https://glama.ai/mcp/servers/KunihiroS/patsnap-mcp/badges/card.svg)](https://glama.ai/mcp/servers/KunihiroS/patsnap-mcp)

Score Badge

Copy to your README.md:

[![patsnap-mcp MCP server](https://glama.ai/mcp/servers/KunihiroS/patsnap-mcp/badges/score.svg)](https://glama.ai/mcp/servers/KunihiroS/patsnap-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/KunihiroS/patsnap-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server