Skip to main content
Glama
Sign In

ClaimHit

by io.github.Bikram2112
OverviewDiscussionsAdmin

Re-run patent search

claimhit_rerun_search

Re-run a previous patent search to get fresh results, repeating the inputs that steered it — the company scope, the hint, named products, markets, company sizes and the named standard. Free within 6 months of the original search, 1 search credit after that. Asks first either way: the initial call returns a quote listing the inputs it will repeat and whether it is free, and runs nothing until you call again with confirm: true. To narrow or re-read the results you already have, use claimhit_get_result instead — that is free and does not start a new search.

Input Schema

NameRequiredDescriptionDefault
widenNoDrop the original company scope and search the whole market. Default false, which repeats the original scope. Use when the first search was scoped to named companies and found too little.
confirmNoSet true only after showing the user the quote from the unconfirmed call and getting their agreement. Without it, nothing is run and nothing is charged.
search_idYesThe search ID of the previous search to re-run

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / confirm
      Added value: +{
+  "default": false,
+  "description": "Set true only after showing the user the quote from the unconfirmed call and getting their agreement. Without it, nothing is run and nothing is charged.",
+  "type": "boolean"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / widen
      Added value: +{
+  "description": "Drop the original company scope and search the whole market. Default false, which repeats the original scope. Use when the first search was scoped to named companies and found too little.",
+  "type": "boolean"
+}
  3. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations cover only the safety/state profile (readOnlyHint=false, idempotentHint=false), so the description carries the real behavioral burden and does so well: cost model (free within 6 months, 1 credit after), a two-phase quote-then-confirm flow, and an explicit guarantee that nothing runs or is charged without confirm:true. This is exactly the context an agent needs before triggering a charged operation.

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 tight sentences, front-loaded with purpose, then cost, then the confirmation mechanic, then the sibling redirect. Every sentence carries distinct, decision-relevant information with no filler.

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

Completeness5/5

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

No output schema exists, but the description still explains the return shape of the unconfirmed call (a quote listing repeated inputs and free/paid status), plus the cost and confirmation semantics. For a 3-parameter, charged re-run tool this is 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%, so the baseline is 3, but the description adds meaning beyond the field docs by framing confirm as part of a quote-approval workflow and by clarifying that the scope inputs (company scope, hint, products, markets, sizes, standard) are repeated from the original search rather than supplied again. That framing materially affects how an agent should present the call to a user.

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?

States a specific verb and resource ('re-run a previous patent search') and enumerates the scope it repeats, so it is immediately distinguishable from claimhit_search (new search) and claimhit_get_result (read existing results). No ambiguity about what the tool does.

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?

Explicitly routes the agent: re-run here, but use claimhit_get_result to narrow or re-read existing results, which is called out as free and non-initiating. The widen parameter guidance ('use when the first search was scoped to named companies and found too little') gives a concrete condition for the main branch.

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

All ClaimHit toolsInspect
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