Patent PreCheck
Server Details
Keyless 12-tool patentability MCP: USPTO pillar scores, prior art, hosted at patentprecheck.com/mcp.
- 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 3.9/5 across 3 of 3 tools scored. Lowest: 3.2/5.
Each tool has a clearly distinct purpose: precheck_pillars provides reference info, precheck_score runs analysis, and precheck_start_review enables follow-up action. No overlap.
All tools follow a consistent 'precheck_' prefix with noun verbs: pillars, score, start_review. Pattern is predictable and clear.
Three tools is well-scoped for a patent pre-check service: one for reference, one for analysis, one for action. No excess or deficiency.
The tool surface covers the core workflow: explain pillars, run a check, and direct to next steps. No obvious gaps for the stated purpose.
Available Tools
12 toolsprecheck_compare_to_patentPatent PreCheck — compare invention to patentAInspect
Compare invention text to a known US patent: embedding similarity plus prior-art risk analysis (statute hints, overlap theme, distinction checklist). Use when the user names a specific reference patent.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Source code or invention description (>= 10 chars). | |
| filename | No | Optional filename hint. | |
| patent_id | Yes | US patent id (e.g. US1234567B2). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses the method (embedding similarity) and outputs (statute hints, overlap theme, distinction checklist), giving a clear picture of the tool's behavior. However, it does not explicitly state that the tool is read-only, though the nature of comparison implies no 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?
Two sentences with no filler. The first sentence states the core function and outputs; the second gives a clear usage condition. Every word serves a 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?
For a tool with 3 parameters, no nested objects, and no output schema, the description adequately explains what the tool returns and when to use it. The output is described in enough detail (embedding similarity, prior-art risk analysis, checklist). It could optionally mention that the tool does not modify any data, but the current completeness is high.
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 description coverage is 100%, so baseline is 3. The description adds no new meaning beyond the schema; it merely restates the patent_id format. It does not provide additional context for the code or filename parameters beyond what the schema already offers.
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's action: 'Compare invention text to a known US patent' and specifies the outputs: embedding similarity, prior-art risk analysis, statute hints, overlap theme, distinction checklist. It also explicitly differentiates itself by noting when to use it, which distinguishes it from siblings like precheck_lookup_patent.
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 includes an explicit usage guideline: 'Use when the user names a specific reference patent.' This tells the agent exactly when to invoke this tool versus alternatives, providing clear context and exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
precheck_cpc_suggestPatent PreCheck — CPC classification hintsAInspect
Suggest Cooperative Patent Classification (CPC) codes for an invention description. Offline heuristic — informational only. No network call.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Source code or invention description (>= 10 chars). | |
| limit | No | Max suggestions (1–10, default 5). |
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 mentions 'No network call' and 'Offline heuristic', but does not disclose any side effects, data handling, or limitations beyond being informational. Additional detail on the heuristic's nature would improve 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?
Two sentences with no fluff. First sentence states purpose clearly; second adds key behavioral notes. Ideal length for a simple tool.
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?
For a tool with 2 well-described parameters and no output schema, the description provides core information: purpose, offline heuristic nature, and that it's informational. It could mention the output format or that suggestions are based on the invention description, but overall it is adequate.
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 both parameters described. The description adds no extra meaning beyond the schema for the parameters. It provides context that the tool is for invention descriptions, but that is already implied by the parameter description. Baseline 3 per rules.
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 suggests CPC codes for invention descriptions, with a specific verb and resource. It distinguishes itself from sibling tools like precheck_prior_art and precheck_rejection_patterns by focusing on classification hints.
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 indicates the tool is an offline heuristic and informational only, giving context on when to use it. However, it does not explicitly mention when not to use it or compare to alternatives, though sibling names make the tool's role fairly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
precheck_deliverablesPatent PreCheck — deliverable download linksAInspect
Return download URLs for finalized ICR deliverables (filing packet, coaching report, package zip, scorecard PDF). Requires report_id and session_key.
| Name | Required | Description | Default |
|---|---|---|---|
| report_id | Yes | Report id (PPC-YYYY-MM-DD-XXXXX). | |
| session_key | Yes | Session secret from the access email (?k=…). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States operation is returning URLs but does not disclose whether it's read-only, side effects, or error conditions. Minimal behavioral context beyond the core action.
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?
Single sentence conveying all essential information without extraneous content. Well-structured and front-loaded with key action and resource.
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?
For a simple tool with two parameters and full schema coverage, the description adequately covers purpose and inputs. Lacks output format details (e.g., whether single URL or list), but overall sufficient for basic 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. Tool description does not add meaning beyond schema descriptions; it merely repeats requirement. No additional clarification on parameter formats or values.
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?
Explicitly states the verb 'return', resource 'download URLs', and lists specific deliverables ('filing packet, coaching report, package zip, scorecard PDF'). Distinguishes from sibling tools which cover different precheck functions.
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?
Clearly states required parameters ('report_id and session_key'), providing necessary context for invocation. However, does not explicitly specify when to use or exclude alternatives, though sibling tool names imply differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
precheck_legal_contextPatent PreCheck — legal intelligence contextAInspect
Return a short snippet of current US software-patent legal guidance (CAFC, USPTO, Alice/§101) relevant to scoring this invention. Informational only — not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Source code or invention description (>= 10 chars). | |
| filename | No | Optional filename hint. |
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 tool is informational and not legal advice, but lacks details on side effects, performance, or required permissions. The tool is likely read-only and safe, but the description provides minimal behavioral context beyond purpose.
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, front-loaded sentence that efficiently conveys the tool's purpose and key constraint. 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?
Given the low complexity and no output schema, the description adequately explains the tool's role in the scoring workflow. It ties to the invention scoring context, though lacks details on snippet length or format.
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 adds no new meaning beyond what the schema provides (e.g., 'code' and 'filename' are described similarly). Baseline score of 3 is appropriate as description does not enhance parameter 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 the tool returns a short snippet of current US software-patent legal guidance relevant to scoring an invention, specifying the resource (legal guidance), action (return), and context (CAFC, USPTO, Alice/§101). It distinguishes itself from siblings like precheck_pillars and precheck_prior_art which cover different aspects.
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 indicates the tool is 'informational only — not legal advice' and states it's 'relevant to scoring this invention', which implies usage context. However, it does not explicitly state when to use versus alternatives or provide exclusions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
precheck_lookup_patentPatent PreCheck — US patent lookupAInspect
Resolve a US patent or application number (e.g. US1234567B2) via USPTO Open Data Portal and optionally join the indexed prior-art corpus. Returns title, status, CPC, grant-text excerpt, and a public URL. No API key required in the MCP client.
| Name | Required | Description | Default |
|---|---|---|---|
| patent_id | Yes | US patent id (US1234567B2) or application number. | |
| include_grant_text | No | Fetch abstract / claim 1 excerpt when available (default true). |
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 that the tool optionally joins the indexed prior-art corpus, which is a behavioral trait. However, it does not mention error handling, rate limits, data freshness, or what happens if the patent ID is invalid. The description partially covers behavior but is not exhaustive.
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 concise with two sentences. The first sentence captures the core action and outputs, the second adds a key benefit (no API key). There is no fluff, and important information is front-loaded.
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 low complexity (2 parameters, no output schema), the description provides a reasonable overview of what the tool returns. It lists the major output fields and hints at the optional join. However, without an output schema, more detail on the return structure would be helpful.
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 description coverage is 100%, so the baseline is 3. The description adds no new meaning for the `patent_id` parameter (it repeats the schema), and for `include_grant_text`, it says 'optionally join the indexed prior-art corpus' which is slightly different from the schema's 'Fetch abstract / claim 1 excerpt'. This could be confusing but does not significantly add value.
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 that the tool resolves a US patent or application number and lists specific outputs (title, status, CPC, grant-text excerpt, public URL). It distinguishes itself from sibling tools like precheck_search_corpus (which searches the corpus) and precheck_prior_art (which finds prior art) by focusing on a single patent lookup.
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 that no API key is required, which is helpful, but it does not provide explicit guidance on when to use this tool versus its siblings (e.g., precheck_prior_art, precheck_search_corpus). The usage context is implied through the tool's purpose but lacks clear exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
precheck_pillarsPatent PreCheck — scoring referenceAInspect
List the five patentability pillars (with statutes and weights) and the band rules used by precheck_score. Use this to explain a score to the user. No network call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral info: 'No network call.' This indicates a local, read-only operation. However, no annotations exist, so the description carries full burden; it could mention more about the static nature of the data or return format. Adequate but not rich.
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 clear, front-loaded sentences with no wasted words. Concise and well-structured.
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 no output schema, the description adequately explains what the tool returns (list with statutes, weights, band rules) and its purpose. A minor gap: 'band rules' not elaborated, but likely contextually clear.
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 exist in the input schema, so the description does not need to add param info. Baseline score of 4 applies.
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 lists the five patentability pillars with statutes and weights, and band rules. It specifies the use case 'explain a score to the user' and distinguishes from siblings by linking to precheck_score.
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 explicitly says 'Use this to explain a score to the user.' This provides a clear usage context. While it does not explicitly list when not to use, the sibling names imply alternatives for scoring and review, making the guidance sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
precheck_prior_artPatent PreCheck — prior art matchesAInspect
Return the closest prior-art matches consulted for an invention (titles, sources, similarity scores, URLs). Runs the same analyze pipeline as precheck_score but focuses on retrieval results. Pass invention text via code.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Source code or invention description (>= 10 chars). | |
| tier | No | Analysis tier. Defaults to free. | |
| limit | No | Max matches to return (1–15, default 8). | |
| filename | No | Optional filename hint. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It indicates the tool retrieves data (return behavior) and runs the same pipeline as precheck_score, but it does not explicitly state if it is read-only, nor does it mention authentication, rate limits, or potential side effects. Adequate but not thorough.
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 exceptionally concise with two sentences: the first defines the output clearly, the second provides context and input instruction. Every word is purposeful, and the structure is front-loaded with key information.
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?
Without an output schema, the description partially compensates by listing output fields (titles, sources, etc.). It also notes the relationship to a sibling tool. However, it could be more complete by describing the output structure or providing additional usage context, but it remains adequate for a tool of this complexity.
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 has 100% coverage with each parameter described. The description adds no additional parameter meaning beyond the schema; it only reiterates that 'code' is the invention text. Thus, it meets the baseline but does not enhance 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 explicitly states the tool returns 'the closest prior-art matches' with specific content (titles, sources, similarity scores, URLs) and distinguishes itself from the sibling precheck_score by noting it focuses on retrieval results rather than scoring. This makes the purpose very clear.
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 provides a clear usage context by comparing with precheck_score ('focuses on retrieval results') and instructs to pass invention text via 'code'. However, it does not explicitly address when not to use it or mention alternatives among all siblings, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
precheck_rejection_patternsPatent PreCheck — rejection pattern previewAInspect
Preview examination-risk signals: similar office-action rejections, abandonment patterns, and the primary statutory basis an examiner might cite (§101/§102/§103). Use after precheck_score to explain prosecution risk.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Source code or invention description (>= 10 chars). | |
| tier | No | Analysis tier. Defaults to free. | |
| filename | No | Optional filename hint. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions 'preview' implying a read-only operation, but does not explicitly state it has no side effects, requires authentication, or has rate limits. It could be more explicit about limitations.
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 sentence plus a short usage instruction. It is concise, front-loaded with the core purpose, and contains no redundant information.
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 lack of output schema, the description provides a reasonable overview of what the tool returns (rejection signals, abandonment patterns, statutory basis). It also contextualizes usage relative to a sibling. It is nearly complete for a preview tool.
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 the input schema already describes all parameters adequately. The tool description does not add additional meaning beyond what the schema provides, so a baseline of 3 is appropriate.
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 previews examination-risk signals including specific rejection types and statutory basis. It distinguishes itself by mentioning it is used after precheck_score, which differentiates it from siblings.
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 explicitly instructs to use after precheck_score to explain prosecution risk, providing clear sequencing. It does not explicitly list when not to use or alternatives, but the context is sufficient for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
precheck_scorePatent PreCheck — score patentabilityBInspect
Run a patentability pre-check on source code or an invention description. Returns a 0–100 patentability score across the four USPTO statutory pillars (§101 eligibility, §102 novelty, §103 non-obviousness, §101 utility), a separate §112 filing-readiness signal, the band (Not Ready → File Ready), the pillar that holds the band back, top opportunities to strengthen, and a count of prior-art matches consulted. Pass the text to analyze inline via code.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The source code or invention description to analyze (>= 10 chars). | |
| tier | No | Analysis tier. Defaults to free; paid tiers require server-side entitlement. | |
| filename | No | Optional filename hint (e.g. main.ts) used for language/context. |
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 for behavioral disclosure. It explains the return values in detail (score, band, pillars, etc.), which adds transparency about output. However, it does not mention side effects, idempotency, failure modes, or prerequisites (e.g., authentication), limiting depth for a tool that may process code submissions.
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 core purpose, then lists return details efficiently. It is reasonably concise, covering essential information without unnecessary words. While it could be shortened slightly, it is well-structured for quick scanning.
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?
The description provides a thorough breakdown of return values, compensating for the lack of an output schema. However, it omits usage guidelines and behavioral context (e.g., whether the tool mutates state or requires permissions), leaving some contextual gaps for agents to infer, especially given the moderate complexity of three parameters.
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?
With 100% schema description coverage, the schema already documents each parameter thoroughly. The description adds minimal extra meaning, merely restating that the text is passed inline via 'code'. It does not enrich parameter understanding beyond the schema baseline, so a score of 3 is appropriate.
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 runs a patentability pre-check and returns a score, which is specific and action-oriented. However, it does not explicitly distinguish this tool from its siblings 'precheck_pillars' and 'precheck_start_review', missing an opportunity to clarify the exact role of this tool.
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 provide any guidance on when to use this tool versus alternatives like 'precheck_pillars' or 'precheck_start_review'. There is no mention of prerequisites, expected use cases, or conditions that would make this tool more appropriate than siblings, leaving the agent without explicit decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
precheck_search_corpusPatent PreCheck — semantic corpus searchAInspect
Fast semantic search against the 1M+ prior-art corpus without LLM scoring. Returns ranked matches with similarity scores. Cheaper than precheck_score when you only need references.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Source code or invention description (>= 10 chars). | |
| tier | No | Search tier. Defaults to free. | |
| limit | No | Max matches (1–20, default 12). | |
| filename | No | Optional filename hint. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It reveals the tool is fast, does not use LLM scoring, and returns ranked matches with similarity scores. It does not disclose potential side effects, authentication needs, or rate limits, which is acceptable for a search tool but still limited.
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 consists of two short, front-loaded sentences with no wasted words. It efficiently conveys the core purpose, unique selling point, and output format.
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?
For a search tool with 4 parameters all explained in the schema, the description covers the essential: corpus size, speed, cost comparison, and output type. Missing details like response structure (e.g., JSON fields) are acceptable given no output schema, and the tool's simplicity means this is nearly complete.
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 description coverage is 100%, so the schema already explains all 4 parameters. The description adds context about the overall function (fast semantic search, no LLM scoring) but does not add meaning beyond what the schema provides for individual parameters. Baseline 3 is justified.
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 it performs 'Fast semantic search against the 1M+ prior-art corpus' with a specific verb (search) and resource (corpus). It distinguishes from sibling precheck_score by noting it is cheaper and lacks LLM scoring, making its unique role clear.
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 implicitly tells when to use this tool ('when you only need references') and contrasts with precheck_score. However, it does not explicitly state when not to use it or list alternatives among the many siblings, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
precheck_session_statusPatent PreCheck — ICR session statusAInspect
Return status for an active Interactive Code Review session. Requires report_id and session_key from the user access email link.
| Name | Required | Description | Default |
|---|---|---|---|
| report_id | Yes | Report id (PPC-YYYY-MM-DD-XXXXX). | |
| session_key | Yes | Session secret from the access email (?k=…). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It describes a read operation (return status) but does not explicitly state lack of side effects or authentication requirements beyond the keys.
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 sentences: first states purpose, second states requirements. No filler, front-loaded, and efficient.
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?
No output schema exists, so the description should provide clues about the response. It does not describe the return format or potential status codes, leaving gaps for an 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% with clear parameter descriptions. The description adds operational context by stating the parameters come from the user access email link, surpassing the baseline.
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 returns status for an active Interactive Code Review session, using a specific verb and resource. It implicitly distinguishes from sibling tools (e.g., precheck_start_review, precheck_score) by focusing on status retrieval.
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 indicates prerequisites (report_id and session_key) but does not specify when to use versus alternatives or when not to use. Sibling tools are listed but not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
precheck_start_reviewPatent PreCheck — start an Interactive Code ReviewAInspect
Return the URL where the user can start a paid (or promo-unlocked) Interactive Code Review that strengthens each pillar with evidence and produces a filing package. Use after precheck_score when the user wants to act on the result.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Optional email hint (prefill only; user confirms on signup). | ||
| promo | No | Optional promo / beta access code (e.g. Beta) to skip payment. | |
| report_id | No | Optional free-score report id (PPC-YYYY-MM-DD-XXXXX) to carry forward. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the tool returns a URL and mentions payment/promo, but does not describe response format, error conditions, or side effects. Adequate but not thorough.
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 sentences, front-loaded with the core return value, no wasted words. Efficiently communicates purpose and usage guidelines.
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?
For a tool with 3 optional params and no output schema, the description covers main usage and parameter roles but lacks details on success/failure behavior or return format structure. Adequate for a starter tool but incomplete.
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 adds useful context: email prefill, promo example, and report ID format. Clarifies practical usage beyond the schema's 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 returns a URL to start an Interactive Code Review, specifies it is paid or promo-unlocked, and distinguishes it from siblings by recommending use after precheck_score when the user wants to act on the result.
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 explicitly says to use after precheck_score when the user wants to act, giving clear context for usage. It does not explicitly state when not to use, but the sibling tool list implies alternatives.
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!