ClaimHit

Get full search results

claimhit_get_result

Read-onlyIdempotent

Get results from a previous ClaimHit search by search ID, and narrow, sort and page through them. FREE and unlimited: every call is a view over results already paid for, so filter and re-read as much as the conversation needs. A search completes in phases: check the returned status field and call again if it is RUNNING, because background enrichment keeps finding additional implementers for several minutes after the first results appear. Only present results as final when status is COMPLETE. Results are paged — if the response carries a more field, there are further matches and you must not present the page you have as the complete list.

Input Schema

Name	Required	Description	Default
`risk`	No	Risk bands to return. Omit for the default list (HIGH and MEDIUM, plus any target found via forward citations and any product the user named). Pass ["LOW"] to see the low-confidence leads, which are excluded by default.
`sort`	No	default = the same order the ClaimHit app shows (documented evidence coverage, then company size); score = Hit Score highest first; name = alphabetical.	default
`limit`	No	Targets per page (default 25, max 100).
`query`	No	Only return targets whose name, company or description contains this text, case-insensitive. Use for narrowing by technology or market words.
`detail`	No	full adds the per-element scores, the evidence source and the stored evidence passages for each target — use it when asked why something scored as it did. Reading evidence is free; a Hit Chart is the paid, element-by-element analysis.	summary
`offset`	No	Skip this many matching targets. Use the offset the previous response's `more` field tells you, to page through the whole list.
`company`	No	Only return targets whose company (or standards body) contains this text, case-insensitive. E.g. "Bosch", "Samsung".
`search_id`	Yes	The search ID returned from claimhit_search or claimhit_get_history
`owner_practice`	No	RETIRED 2026-10-31 and ignored: the owner-practice flag it filtered on has been removed, so no rows are filtered by it and the response says so. Still accepted so an existing caller is not rejected. Do not use it.	include
`include_held_low`	No	Also return candidates held back for re-verification (not findings yet, flagged held_low). Default false.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 31, 2026

changedInput schema / properties / owner_practice / description

Previous value: -"How to treat rows where the PATENT OWNER (or a company in its group) appears to practise its own claim — they are flagged `practised_by_the_owner` and are never counted as infringers. include (default) keeps them, exclude gives a third-party-only list, only answers \"does the owner work this claim\" on its own."New value: +"RETIRED 2026-10-31 and ignored: the owner-practice flag it filtered on has been removed, so no rows are filtered by it and the response says so. Still accepted so an existing caller is not rejected. Do not use it."

Changed1 schema field changedOct 19, 2026

addedInput schema / properties / owner_practice

Added value: +{
+  "default": "include",
+  "description": "How to treat rows where the PATENT OWNER (or a company in its group) appears to practise its own claim — they are flagged `practised_by_the_owner` and are never counted as infringers. include (default) keeps them, exclude gives a third-party-only list, only answers \"does the owner work this claim\" on its own.",
+  "enum": [
+    "include",
+    "only",
+    "exclude"
+  ],
+  "type": "string"
+}

Changed8 schema fields changedOct 15, 2026

addedInput schema / properties / company

Added value: +{
+  "description": "Only return targets whose company (or standards body) contains this text, case-insensitive. E.g. \"Bosch\", \"Samsung\".",
+  "type": "string"
+}

addedInput schema / properties / detail

Added value: +{
+  "default": "summary",
+  "description": "full adds the per-element scores, the evidence source and the stored evidence passages for each target — use it when asked why something scored as it did. Reading evidence is free; a Hit Chart is the paid, element-by-element analysis.",
+  "enum": [
+    "summary",
+    "full"
+  ],
+  "type": "string"
+}

addedInput schema / properties / include_held_low

Added value: +{
+  "description": "Also return candidates held back for re-verification (not findings yet, flagged held_low). Default false.",
+  "type": "boolean"
+}

addedInput schema / properties / limit

Added value: +{
+  "default": 25,
+  "description": "Targets per page (default 25, max 100).",
+  "type": "number"
+}

addedInput schema / properties / offset

Added value: +{
+  "default": 0,
+  "description": "Skip this many matching targets. Use the offset the previous response's `more` field tells you, to page through the whole list.",
+  "type": "number"
+}

addedInput schema / properties / query

Added value: +{
+  "description": "Only return targets whose name, company or description contains this text, case-insensitive. Use for narrowing by technology or market words.",
+  "type": "string"
+}

addedInput schema / properties / risk

Added value: +{
+  "description": "Risk bands to return. Omit for the default list (HIGH and MEDIUM, plus any target found via forward citations and any product the user named). Pass [\"LOW\"] to see the low-confidence leads, which are excluded by default.",
+  "items": {
+    "enum": [
+      "HIGH",
+      "MEDIUM",
+      "LOW"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / sort

Added value: +{
+  "default": "default",
+  "description": "default = the same order the ClaimHit app shows (documented evidence coverage, then company size); score = Hit Score highest first; name = alphabetical.",
+  "enum": [
+    "default",
+    "score",
+    "name"
+  ],
+  "type": "string"
+}

First observedJul 14, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations only establish read-only/idempotent safety; the description adds the genuinely non-obvious traits: calls are free and unlimited, enrichment continues for minutes after first results, and results are incomplete while a `more` field is present. Those are exactly the behaviors an agent would otherwise get wrong.

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?

Front-loaded with purpose and cost model, then the two failure modes (RUNNING status, `more` paging) as separate sentences. Slightly long for its content, but every sentence carries an actionable instruction.

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 supplies the key return-field semantics (status, more) and the paid-vs-free boundary against Hit Charts. It does not describe the shape of a target record itself, which for a 10-parameter read tool is the main remaining gap.

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% and each parameter has its own explanatory description, so the schema does the heavy lifting. The description adds only indirect parameter guidance (consult `status`, use the offset from `more`) rather than explaining the filter/sort/detail options. Baseline 3 applies.

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 — retrieve results of a previous search by search ID — plus the transformations it supports (narrow, sort, page). It is clearly distinguishable from claimhit_search (which creates the search) and from claimhit_get_history without needing the sibling schemas.

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 when to call repeatedly ('filter and re-read as much as the conversation needs'), when to poll again (status RUNNING), and when results may be treated as final (COMPLETE). It doesn't contrast with claimhit_rerun_search or claimhit_get_history for the case where results are stale, which is the one open routing question.

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

All ClaimHit tools Inspect

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.

Get full search results

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources