Skip to main content
Glama

Patent PreCheck

by io.github.Patent-PreCheck
OverviewDiscussionsAdmin

Server Details

Keyless 12-tool patentability MCP: USPTO pillar scores, prior art, hosted at patentprecheck.com/mcp.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP
URL

TDQS

A3.9/5.0

Scored across 12 tools

Disambiguation3/5

Most tools have distinct jobs, but precheck_prior_art, precheck_search_corpus, and precheck_compare_to_patent all return prior-art matches and could be confused; precheck_rejection_patterns also overlaps somewhat with the statute-hint analysis in precheck_compare_to_patent. Descriptions do clarify target use cases (named patent vs cheap corpus search vs retrieval after scoring), but an agent must read carefully to pick correctly.

Naming Consistency4/5

All tools share the precheck_ prefix and consistent snake_case formatting, which creates a clear family identity. The sub-names mix verb_noun forms (lookup_patent, search_corpus, start_review) with noun-only forms (deliverables, pillars, rejection_patterns), so the naming convention is mostly consistent but not uniform.

Tool Count5/5

12 tools is well-scoped for a patentability precheck service: core scoring, prior-art search, CPC suggestions, legal context, review session handling, and deliverables each get dedicated tools. The count is reasonable and no tool feels redundant enough to cut.

Completeness5/5

The tool surface covers the full workflow: scoring an invention (precheck_score), explaining and contextualizing it (precheck_pillars, precheck_legal_context, precheck_rejection_patterns), retrieving prior art (precheck_search_corpus, precheck_prior_art, precheck_lookup_patent, precheck_compare_to_patent), and acting on results (precheck_start_review, precheck_session_status, precheck_deliverables). There are no obvious dead ends or missing lifecycle steps for the stated domain.

Available Tools

12 tools
precheck_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.

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesSource code or invention description (>= 10 chars).
filenameNoOptional filename hint.
patent_idYesUS patent id (e.g. US1234567B2).

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. It lists the analysis components (embedding similarity, prior-art risk analysis, etc.) but does not disclose if the tool is read-only, modifies data, or any side effects. The description implies a read operation but lacks explicit behavioral traits.

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?

Two sentences, each earning its place: first states purpose and output, second gives usage guidance. No extraneous words, front-loaded.

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 no output schema, the description covers key output components (embedding similarity, prior-art risk analysis, statute hints, overlap theme, distinction checklist). It also provides usage context. Missing details like output format or limitations, but adequate for a comparison 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 baseline is 3. The description adds minimal detail beyond the schema: it reinforces that 'code' is invention text and 'patent_id' is the target patent. No additional parameter semantics beyond schema descriptions.

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 compares invention text to a known US patent with specific analyses (embedding similarity, prior-art risk analysis, statute hints, overlap theme, distinction checklist). It also explicitly distinguishes from siblings by stating 'Use when the user names a specific reference patent.'

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?

Provides explicit guidance: 'Use when the user names a specific reference patent.' This clearly indicates the condition for use but does not provide explicit when-not or alternative tools, though sibling context implies differentiation.

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 hintsBInspect

Suggest Cooperative Patent Classification (CPC) codes for an invention description. Offline heuristic — informational only. No network call.

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesSource code or invention description (>= 10 chars).
limitNoMax suggestions (1–10, default 5).
invention_kindNoOptional invention category. Physical/process uses article and method CPC classes, not G06F.

TDQS

B3.4/5.0
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. It does disclose 'Offline heuristic — informational only. No network call,' which is useful behavioral context implying low latency and non-authoritative results. However, it omits any detail about side effects, deterministic behavior, or whether it is read-only (though 'suggest' implies). It adds some value but could go further given zero annotation coverage.

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 two sentences with zero fluff. The primary purpose is front-loaded, and the behavioral caveat follows immediately. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple suggestion tool with fully documented parameters and no output schema, the description is largely sufficient: it names the input, the purpose, and two key behavioral traits. The only gap is that it doesn't describe what the response looks like (e.g., a list of codes with confidence scores), which would help the agent know what to expect. Given the low complexity, this is a minor omission.

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 baseline is 3. The description adds only a general reference to 'invention description,' which maps to the 'code' parameter, but does not elaborate on 'limit' or 'invention_kind' beyond what the schema already provides. It does not compensate for any schema gaps because there are none.

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 states the specific action 'Suggest' and the resource 'Cooperative Patent Classification (CPC) codes for an invention description,' which clearly distinguishes it from prior-art or legal-context tools. However, it does not name an alternative sibling or explicitly differentiate itself from the many other precheck_* tools, so it stops short of the highest tier.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives like precheck_prior_art or precheck_rejection_patterns. The description never mentions conditions like 'if the user needs classification hints' or 'when exploring patent categories.' The agent must infer usage from the name alone.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
report_idYesReport id (PPC-YYYY-MM-DD-XXXXX).
session_keyYesSession secret from the access email (?k=…).

TDQS

A3.8/5.0
Behavior3/5

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

The description discloses that it returns download URLs (not files) and requires a session_key for access, which implies a credential-based security model. However, with no annotations provided, the description does not explicitly state whether the operation is read-only, what happens if parameters are invalid, or potential timeout/rate limits. It is minimally transparent but not misleading.

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 extremely concise with two front-loaded sentences: the first states purpose and deliverables, the second states requirements. No extraneous information, every sentence earns its place. This is optimal for quick agent comprehension.

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 simplicity (2 required params, no output schema), the description covers the core functionality well. It mentions return type (URLs) but does not specify the response structure or mention potential error scenarios (e.g., invalid report_id). The absence of an output schema is not fully compensated, but the description provides sufficient context for most use cases.

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 input schema has 100% coverage, describing both report_id and session_key. The description adds minor context (e.g., report_id format hint and session_key origin from access email), but these are essentially redundant with the schema descriptions. Since the schema already provides clear definitions, the description adds limited semantic value beyond what is structured.

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 returns download URLs for specific deliverables (filing packet, coaching report, package zip, scorecard PDF). The verb 'Return' and the explicit enumeration of deliverables make the purpose unambiguous, distinguishing it from sibling tools that focus on different stages (e.g., precheck_score, precheck_search_corpus).

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 notes required parameters (report_id and session_key) but does not provide explicit guidance on when to use this tool versus alternatives. It implies usage when deliverables are needed after review completion, but lacks when-not-to-use conditions or direct references to sibling tools for context. This is adequate but leaves 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_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.

ParametersJSON Schema
NameRequiredDescriptionDefault
patent_idYesUS patent id (US1234567B2) or application number.
include_grant_textNoFetch abstract / claim 1 excerpt when available (default true).

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the transparency burden. It discloses the data source (USPTO), optional prior-art corpus join, and lack of auth requirements. It does not mention error handling or rate limits, but for a simple lookup this is sufficient.

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?

Two sentences pack all essential information: the operation, source, optional feature, return fields, and auth requirement. No redundancy or filler.

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?

The description lists the return fields and mentions the optional join, which is adequate for a simple lookup tool. It does not cover error cases or pagination, but given the tool's straightforward nature, it is mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and descriptions already document both parameters. The description adds value with an example patent ID, clarifies the optional excerpt behavior, and explains the prior-art corpus join (a feature tied to the tool's behavior). This exceeds the baseline of 3.

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 resolves a US patent/application number and returns specific fields like title, status, CPC, excerpt, and URL. This distinguishes it from sibling tools that perform comparisons, suggestions, or searches.

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 implies use when basic patent info is needed and notes no API key is required, but does not explicitly state when to prefer this tool over alternatives like precheck_search_corpus or precheck_prior_art. No when-not-to-use guidance is provided.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.4/5.0
Behavior4/5

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

No annotations provided, so description carries burden; it discloses 'No network call' implying read-only and fast behavior, but doesn't confirm lack of side effects beyond that.

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?

Two sentences, front-loaded with purpose and usage, every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with no output schema, the description fully explains what it returns at a high level, though specifics of pillars could be inferred as output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters, so schema coverage is 100% trivially; description adds no param info, but none is needed.

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?

Description clearly states the tool lists patentability pillars with statutes/weights and band rules, distinguishing it from sibling tools like precheck_score by specifying its use for explaining a score.

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?

Explicitly says 'Use this to explain a score to the user' and notes 'No network call', providing clear context for when to use, though no explicit alternatives are given.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesSource code or invention description (>= 10 chars).
tierNoAnalysis tier. Defaults to free.
limitNoMax matches to return (1–15, default 8).
filenameNoOptional filename hint.

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description must carry the full burden. It notes the pipeline similarity to precheck_score and mentions return fields but lacks details on destructive potential, authentication, or rate limits. Being a read-like retrieval tool, the transparency is 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with purpose, no fluff. Every sentence adds value: what it returns, how it differs from a sibling, and how to input.

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 no output schema, it lists return fields. It references the pipeline of precheck_score for context. Could be improved by describing the output format (e.g., array ordering) or handling of edge cases, but it is largely complete for a retrieval 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 coverage is 100%, so baseline is 3. The description only adds 'Pass invention text via `code`' which restates the schema; it does not elaborate on tier, limit, or filename beyond what the schema provides.

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 it returns prior-art matches with specific fields (titles, sources, similarity scores, URLs) and explicitly differentiates from precheck_score by focusing on retrieval results, providing a specific verb-resource pair.

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 implies usage for retrieval results and contrasts with precheck_score, but does not explicitly list when to avoid using it or provide alternatives among the many sibling tools.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesSource code or invention description (>= 10 chars).
tierNoAnalysis tier. Defaults to free.
filenameNoOptional filename hint.

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description must disclose behavioral traits. The word 'preview' implies no destructive side effects, but it does not explicitly state if the tool is read-only, if it has rate limits, or if it makes external calls. More detail would be helpful.

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?

Two sentences that efficiently convey purpose, output, and usage context. Every word is meaningful and well-structured for quick parsing.

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?

The description adequately explains what the tool does and when to use it. Since there is no output schema, it could mention the return format or additional details like whether results are cached, but it is sufficiently complete 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 coverage is 100%, so baseline is 3. The description adds nothing beyond the schema for parameters. It does not clarify formats, constraints, or relationships between parameters.

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: to preview examination-risk signals such as similar office-action rejections, abandonment patterns, and statutory basis. It also distinguishes it from siblings by specifying it should be used after precheck_score.

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 explicitly says 'Use after precheck_score to explain prosecution risk,' providing clear context for when to use this tool. However, it does not explicitly mention when not to use it or alternatives.

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 patentabilityAInspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesThe source code or invention description to analyze (>= 10 chars).
tierNoAnalysis tier. Defaults to free; paid tiers require server-side entitlement.
filenameNoOptional filename hint (e.g. main.ts) used for language/context.
invention_kindNoOptional invention category. Sets language and scoring prompts. Prior-art math still follows the disclosure.

TDQS

A3.9/5.0
Behavior4/5

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

No annotations are present, so the description carries the behavioral burden. It does this well by enumerating what is evaluated (four statutory pillars plus §112), what is returned, and that prior art is consulted. It does not explicitly disclose side effects, rate limits, or auth requirements, but the operation is clearly an analysis-and-return tool rather than a mutation.

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 one dense sentence, but every clause adds either a deliverable or an input constraint. It is front-loaded with the action and resource, though a bulleted output list would improve scannability.

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?

With no output schema, the description spells out the full return surface (score, band, blocking pillar, opportunities, prior-art count), so an agent can interpret results. It does not orient the agent among the many siblings, but that gap is primarily a usage-guidance issue rather than an invocation-completeness issue.

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 coverage is 100%, so the input schema already documents all four parameters. The description adds only the inline-via-code nuance and the phrase 'source code or invention description' for `code`; it does not add meaning for `tier`, `filename`, or `invention_kind` beyond what the schema already provides.

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 names a concrete verb ('Run'), a specific resource ('patentability pre-check on source code or an invention description'), and a detailed output contract (score, §112 signal, band, opportunities, prior-art count). This clearly differentiates it from sibling tools like precheck_compare_to_patent or precheck_cpc_suggest by the overall scoring function.

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 intended scenario is implied: use this when a user has source code or invention text and wants a single patentability score. However, it does not explicitly say when to use this instead of precheck_pillars, precheck_prior_art, or precheck_compare_to_patent, nor does it list exclusions or conditions.

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 2M+ prior-art corpus without LLM scoring. Returns ranked matches with similarity scores. Cheaper than precheck_score when you only need references.

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesSource code or invention description (>= 10 chars).
tierNoSearch tier. Defaults to free.
limitNoMax matches (1–20, default 12).
filenameNoOptional filename hint.

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it is fast, semantic, returns ranked matches with similarity scores, and does not use LLM scoring. It also implies lower cost. These details go beyond a generic statement and help the agent anticipate output and tradeoffs, though it does not cover potential errors or limits.

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 three short sentences, each contributing essential information: what it is, what it returns, and when to use it over an alternative. It is front-loaded with the core function and contains no filler or redundant phrasing.

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 moderate complexity (4 params, 1 required, no output schema), the description covers the return value ('ranked matches with similarity scores'), the corpus size, and the speed/cost tradeoff. It could be more detailed about the exact output format (e.g., fields per match), but it provides sufficient context for an agent to decide and invoke correctly.

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 input schema has 100% coverage with meaningful descriptions for all four parameters, so the baseline is 3. The description does not add new parameter-level details beyond what the schema provides, but it does reinforce the main use case (code search) without redundancy. It neither elevates nor diminishes the schema's clarity.

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 a specific verb ('search') and a specific resource ('the 2M+ prior-art corpus'), and distinguishes the tool from siblings by noting 'without LLM scoring' and implying a different cost profile than precheck_score. This is a strong, differentiated purpose.

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 explicitly recommends this tool over precheck_score ('Cheaper than precheck_score') and specifies the condition ('when you only need references'). While it does not explicitly list exclusions or other alternatives, the primary alternative is clearly identified, giving actionable guidance.

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 statusBInspect

Return status for an active Interactive Code Review session. Requires report_id and session_key from the user access email link.

ParametersJSON Schema
NameRequiredDescriptionDefault
report_idYesReport id (PPC-YYYY-MM-DD-XXXXX).
session_keyYesSession secret from the access email (?k=…).

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It does not disclose whether the operation is read-only or has side effects, nor any auth or rate limits beyond the parameter requirements.

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?

Two concise sentences: first states purpose, second lists requirements. No wasted words.

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?

Adequate for a simple status retrieval with clear inputs, but lacks information about the output format or possible errors, given no output schema or annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions already. The description adds context that the parameters come from an 'access email link,' which enhances understanding beyond the schema alone.

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 'Return status for an active Interactive Code Review session,' specifying the verb and resource. It is distinct from siblings like precheck_start_review, though it does not explicitly contrast with them.

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 implies usage for checking session status and mentions required parameters from an access email, but does not provide guidance on when to use this tool vs. alternatives, nor any exclusions.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
emailNoOptional email hint (prefill only; user confirms on signup).
promoNoOptional promo / beta access code (e.g. Beta) to skip payment.
report_idNoOptional free-score report id (PPC-YYYY-MM-DD-XXXXX) to carry forward.

TDQS

A3.8/5.0
Behavior3/5

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

Discloses that the review is paid or promo-unlocked and produces a filing package. No annotations; description lacks information on authentication, side effects, or what happens after URL is returned.

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?

Two sentences, no unnecessary words, effectively front-loads purpose and usage guideline.

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?

Provides enough context for a simple tool with optional parameters and no output schema. Missing explicit instruction on what to do with the URL, but overall it's clear.

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 coverage is 100% with descriptions for all 3 parameters. The description adds minimal value beyond the schema, such as an example for 'promo'. Baseline score 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 returns a URL to start a specific review, and mentions it's used after precheck_score. However, it does not fully distinguish from all sibling tools, only referencing one.

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?

Explicitly tells when to use: after precheck_score when the user wants to act. Provides clear context but no exclusions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updates
    • Changedprecheck_cpc_suggest1 field changed
      • addedInput schema / properties / invention_kind
        Added value: +{
+  "description": "Optional invention category. Physical/process uses article and method CPC classes, not G06F.",
+  "enum": [
+    "software",
+    "physical",
+    "process",
+    "unsure"
+  ],
+  "type": "string"
+}
    • Changedprecheck_score1 field changed
      • addedInput schema / properties / invention_kind
        Added value: +{
+  "description": "Optional invention category. Sets language and scoring prompts. Prior-art math still follows the disclosure.",
+  "enum": [
+    "software",
+    "physical",
+    "process",
+    "unsure"
+  ],
+  "type": "string"
+}
  2. 2 tool updates
    • Addedprecheck_compare_to_patent
    • Addedprecheck_lookup_patent
  3. 4 tool updates
    • Addedprecheck_cpc_suggest
    • Addedprecheck_deliverables
    • Addedprecheck_search_corpus
    • Addedprecheck_session_status
  4. 4 tool updates
    • Addedprecheck_legal_context
    • Addedprecheck_prior_art
    • Addedprecheck_rejection_patterns
    • Changedprecheck_start_review3 fields changed
      • addedInput schema / properties / email
        Added value: +{
+  "description": "Optional email hint (prefill only; user confirms on signup).",
+  "type": "string"
+}
      • addedInput schema / properties / promo
        Added value: +{
+  "description": "Optional promo / beta access code (e.g. Beta) to skip payment.",
+  "type": "string"
+}
      • addedInput schema / properties / report_id
        Added value: +{
+  "description": "Optional free-score report id (PPC-YYYY-MM-DD-XXXXX) to carry forward.",
+  "type": "string"
+}
  5. 3 tool updates
    • First observedprecheck_pillars
    • First observedprecheck_score
    • First observedprecheck_start_review

Related MCP Connectors

Related MCP Servers

Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources