Free anonymous selections from released European IP profiles, rankings, and market statistics.
Scored across 6 tools
The generic `fetch` overlaps heavily with `get_ip_representative_profile` (both return one representative profile) and with `get_ip_market_snapshot` (fetch explicitly reads market snapshots), so an agent may not know which to call for a given document. `find_ip_representatives` and `search` also overlap in that both locate firms/attorneys, only differing by structured filters vs. open query.
Four tools follow a `verb_noun` pattern with an `ip` prefix (get_ip_market_snapshot, get_iprate_coverage, find_ip_representatives, get_ip_representative_profile), but `fetch` and `search` are bare verbs that break the convention. It remains readable but is genuinely mixed.
Six tools is well-scoped for a read-only IP data service, and each maps to a distinct retrieval mode (discover, read document, filter firms, snapshot, coverage, profile). No tool feels redundant in count terms.
For a static, read-only published dataset the surface is nearly complete: discovery (search/find), retrieval (fetch/profile), aggregation (market snapshot), and coverage explanation. The only minor gap is that arbitrary/date-based querying is explicitly unsupported, which is a design choice rather than a missing operation.
Use this after search to read one document in full: a published representative profile with its released ratings, a market snapshot with released statistics and leading firms, or a coverage summary. Returns the text, the public URL to cite, and release metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Document id returned by search, such as firm:<slug> or market:LT:trademark:national:long. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | Public IPRATE page to cite. |
| text | Yes | Full document text. |
| title | Yes | |
| metadata | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is fully covered and the description does not contradict it. What it adds is that the payload is the full document text plus a public citation URL and release metadata, but that return detail largely duplicates the output schema. For a read-only tool with complete annotations, this is 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 sentences, with the usage directive front-loaded before the payload description. The middle enumeration of document types is long but each clause carries real information about what can be fetched, so there is little waste.
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?
Complexity is low (one required id, read-only, output schema present), and the description covers the workflow hook and the return contents. The one meaningful omission is routing between fetch and its three typed-getter siblings, which an agent calling this tool correctly would benefit from knowing.
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?
There is only one parameter and schema description coverage is 100%; the schema already documents the id and even gives example id forms (firm:<slug>, market:LT:trademark:national:long). The description adds nothing about id format or origin beyond the generic "after search", so the baseline 3 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 names a specific verb (read one document in full) and resource (an IPRATE evidence document), and enumerates the three document shapes it can return, so an agent knows what it gets back. However, those three shapes map almost one-to-one onto the sibling tools get_ip_representative_profile, get_ip_market_snapshot and get_iprate_coverage, and the description never distinguishes itself from them, leaving a real ambiguity about which entry point to use.
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?
"Use this after search" gives explicit sequencing: search yields ids, fetch consumes them. That is clear when-to-use guidance. It does not state when NOT to use it versus the typed getters, so the alternative-selection rule is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find up to five firms or attorneys from the selected static release. Use this for a name, jurisdiction, right type, released leading Nice class, or released leading-client match. At least one filter is required.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Representative name fragment, matched against released profile identities. | |
| tier | No | Optional released national or European route. | |
| limit | No | Maximum results; hard maximum five. | |
| window | No | Optional released long or recent analytical window. | |
| right_type | No | IP right type. | |
| client_name | No | Named client to match against leading-client evidence already public on profiles. | |
| jurisdiction | No | ISO 3166-1 alpha-2 jurisdiction code, or EU for the European route. | |
| nice_classes | No | One to five Nice class numbers; trademark only. | |
| representative_type | No | Return firms, attorneys, or both. | both |
| Name | Required | Description |
|---|---|---|
| data | Yes | Tool result. Which fields are present depends on status. |
| as_of | Yes | Generation time of the selected static release. |
| links | Yes | |
| status | Yes | |
| coverage | Yes | |
| release_id | Yes | |
| limitations | Yes | |
| source_urls | Yes | Public URLs to cite. |
| server_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral context not present in the structured fields: results are capped ('up to five') and at least one filter must be supplied — the latter is important since the schema marks zero required parameters. It omits nothing critical for a static read.
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, no filler, with the result cap and source scope front-loaded before the usage guidance and the mandatory-filter constraint. Every clause earns its place.
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?
With an output schema present, return values need not be explained, and the description covers what the tool returns (firms/attorneys), how many (up to five), and the input constraint. It is nearly complete; only the distinction from get_ip_representative_profile and 'search' is left implicit.
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 and the schema carries the parameter burden. The description nonetheless maps its filter list onto the actual parameters (name, jurisdiction, right_type, nice_classes, client_name) and adds the cross-parameter rule that at least one must be set, which the schema's empty required array does not convey.
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 states a specific verb and resource ('Find up to five firms or attorneys') plus a scope qualifier ('from the selected static release'), which is enough for an agent to know it is a search/lookup tool. It does not explicitly name or differentiate itself from the closest sibling, get_ip_representative_profile, which retrieves a single representative, so it stops short of a 5.
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?
'Use this for a name, jurisdiction, right type, released leading Nice class, or released leading-client match' gives clear trigger conditions, and 'At least one filter is required' states the entry constraint. It stops at 4 because it never says when NOT to use it or which sibling to prefer for a single-profile lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one already-computed static cohort snapshot and up to five leading released firms. No dates, raw records, SQL, arbitrary grouping, or free-form question are accepted.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | Yes | Released national or European route. | |
| window | Yes | Released long or recent analytical window. | |
| right_type | Yes | IP right type. | |
| jurisdiction | Yes | ISO 3166-1 alpha-2 jurisdiction code. |
| Name | Required | Description |
|---|---|---|
| data | Yes | Tool result. Which fields are present depends on status. |
| as_of | Yes | Generation time of the selected static release. |
| links | Yes | |
| status | Yes | |
| coverage | Yes | |
| release_id | Yes | |
| limitations | Yes | |
| source_urls | Yes | Public URLs to cite. |
| server_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world, non-destructive. The description adds meaning beyond them: the snapshot is 'already-computed static' and the firm list is capped at five, telling the agent the output is a fixed shape rather than a queryable result set.
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 tight sentences, zero filler, with the return shape front-loaded ahead of the constraint list.
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?
An output schema exists, so return-value documentation is not required. The description covers scope and output shape for a fixed-snapshot tool; only the exclusion-to-alternative mapping is missing.
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% and three of four parameters carry enum descriptions, so the schema fully documents inputs. The description adds no parameter-level detail (e.g., what 'long' vs 'recent' windows mean), so the baseline 3 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?
States a specific verb and resource (return a static cohort snapshot plus up to five leading firms), which is clear and concrete. It does not name any sibling tool, so differentiation from fetch/search/find_ip_representatives is left to inference.
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?
Explicitly states what is not accepted (dates, raw records, SQL, arbitrary grouping, free-form questions), which strongly scopes when this tool applies. However, it never names the alternative tool to use for those cases, so the routing signal is negative-only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain which static release cohorts support a jurisdiction and IP-right question. Returns held, partial, or not-covered state, release assets, counts, and supported fields.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Optional released national or European route. | |
| right_type | No | Optional IP right type. | |
| jurisdiction | No | Optional ISO 3166-1 alpha-2 code, or EU for the European route. |
| Name | Required | Description |
|---|---|---|
| data | Yes | Tool result. Which fields are present depends on status. |
| as_of | Yes | Generation time of the selected static release. |
| links | Yes | |
| status | Yes | |
| coverage | Yes | |
| release_id | Yes | |
| limitations | Yes | |
| source_urls | Yes | Public URLs to cite. |
| server_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description's added behavioral value is the tri-state semantics (held / partial / not-covered), but it then spends its remaining budget listing return fields that the existing output schema already documents.
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 tight sentences with no padding, and the purpose is front-loaded before the return-value list. The second sentence is largely a restatement of the output schema, which costs a little, but the overall size is appropriate.
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?
With an output schema and full annotations present, the description only needs to carry intent; it does that. However, it leaves gaps on how this capability check relates to the other IP tools and on the fact that all parameters are optional (i.e. what a call with no arguments returns).
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% and all three parameters carry their own descriptions plus enums for tier and right_type, so the schema does the heavy lifting. The description only gestures at 'jurisdiction and IP-right question' and adds no format, default, or combination semantics beyond that (e.g. that tier and right_type are optional filters).
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?
States a concrete verb (explain/check support) and a specific resource (static release cohort coverage for a jurisdiction + IP-right question), and enumerates the resulting states. It is clear what the tool answers, though it never names or contrasts a sibling tool such as get_ip_market_snapshot or search.
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?
Usage is only implied: the notion of coverage states suggests a preflight/capability check before running a data query, but the description never says when to call this instead of the siblings (fetch, search, get_ip_market_snapshot). No prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the bounded public evidence profile for one published IP firm or attorney. Provide exactly one numeric representative_id or public profile slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Exact public IPRATE profile slug. | |
| representative_id | No | Published representative numeric ID. | |
| representative_type | No | Disambiguates an identifier shared by firm and attorney profiles. |
| Name | Required | Description |
|---|---|---|
| data | Yes | Tool result. Which fields are present depends on status. |
| as_of | Yes | Generation time of the selected static release. |
| links | Yes | |
| status | Yes | |
| coverage | Yes | |
| release_id | Yes | |
| limitations | Yes | |
| source_urls | Yes | Public URLs to cite. |
| server_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, covering the safety profile. The description adds the constraint of providing exactly one identifier, which is useful context, but doesn't disclose return format, rate limits, or other behavioral traits. With annotations covering safety, a 3 is appropriate.
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 action and resource, followed by the key constraint. No waste, every word earns its place.
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 tool's simplicity, the presence of a full output schema, and comprehensive annotations, the description is nearly complete. It could mention the output is a 'bounded' profile which hints at scope, but doesn't specify any limitations or prerequisites beyond the identifier constraint. However, for a read-only retrieval tool, this is largely sufficient.
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 documents slug, representative_id, and representative_type fully. The description adds the requirement of 'exactly one' identifier, which is a semantic constraint not explicitly in the schema, but otherwise doesn't expand on parameter meanings.
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?
States a specific verb ('Return') and resource ('bounded public evidence profile for one published IP firm or attorney'), which is clear enough to distinguish from siblings like find_ip_representatives. It doesn't explicitly name which sibling to use instead, but the scope is well-defined.
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 implies usage by requiring exactly one identifier ('Provide exactly one numeric representative_id or public profile slug'), which constrains the call. However, it doesn't state when to use this tool versus find_ip_representatives or get_ip_market_snapshot, leaving the choice implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this for open research about European IP firms, IP attorneys, or an IP market, such as who leads trademark work in a country or what IPRATE publishes about a named firm. Returns up to ten documents (representative profiles, market snapshots, coverage summaries) with ids for fetch and public URLs to cite. It searches one completed static IPRATE release, not the official registers; a missing result does not prove that a representative does not exist.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free text: a firm or attorney name, a country, an IP right type (trademark, design, patent), or a combination such as 'patent firms Germany'. |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: the result cap (up to ten documents), the document genres returned, the presence of public URLs for citation, the static completed-release scope, and the important caveat that a miss does not disprove existence. The annotations already cover the read-only/idempotent profile, and the description enriches rather than repeats them.
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?
Three sentences, each carrying distinct information: purpose/audience, return shape and citation affordance, then scope limitation. Front-loaded with the intended use case and free of filler.
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 one-parameter search with an output schema, the description supplies everything the schema and annotations cannot: what kind of corpus is searched, result volume, the ids that link to fetch, and the epistemological caveat about missing results.
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?
There is a single parameter with 100% schema description coverage, so the schema already documents accepted query forms and the 256-character limit. The description's examples of query content ('patent firms Germany') echo the schema rather than extending it, so the baseline 3 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?
States a specific verb (search) and resource (IPRATE published evidence about European IP firms, attorneys, markets) and scopes it to open research queries. An agent can distinguish it from fetch, which consumes the ids this tool returns.
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?
Explicitly frames when to use it ('open research about European IP firms... who leads trademark work in a country') and routes onward via the returned ids for fetch. It also excludes the official registers and warns that absence of a result is not proof of absence, though it does not contrast itself with find_ip_representatives or get_ip_representative_profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
fetchfind_ip_representatives1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "as_of": {
+ "description": "Generation time of the selected static release.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "coverage": {
+ "properties": {
+ "availability": {
+ "type": "string"
+ },
+ "error_type": {
+ "type": "string"
+ },
+ "exclusions": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "hold_state": {
+ "type": "string"
+ },
+ "jurisdiction": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "right_type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "static_assets": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "tier": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "data": {
+ "description": "Tool result. Which fields are present depends on status.",
+ "properties": {
+ "items": {
+ "items": {
+ "properties": {
+ "city": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "home_country_code": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "matching_cohort": {
+ "properties": {
+ "jurisdiction": {
+ "type": "string"
+ },
+ "leading_clients": {
+ "items": {
+ "properties": {
+ "quoted_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "share_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "published_rating": {
+ "description": "Rating copied from the release: score, tier code (Q1 Elite to Q4 Select), confidence grade, rank.",
+ "properties": {
+ "confidence": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "score": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "tier": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "released_activity": {
+ "properties": {
+ "case_units": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "registration_rate": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "time_to_grant_days": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "total_firms_filing": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_per_year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "right_type": {
+ "type": "string"
+ },
+ "tier": {
+ "type": "string"
+ },
+ "top_classes": {
+ "items": {
+ "properties": {
+ "class_code": {
+ "type": [
+ "string",
+ "number",
+ "null"
+ ]
+ },
+ "class_label": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "share_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "window": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "profile_url": {
+ "type": "string"
+ },
+ "quoted_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "representative_id": {
+ "type": "number"
+ },
+ "representative_type": {
+ "type": "string"
+ },
+ "text_provenance": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "message": {
+ "description": "Explanation when status is not ok.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "limitations": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "links": {
+ "properties": {
+ "explore": {
+ "type": "string"
+ },
+ "methodology": {
+ "type": "string"
+ },
+ "request_analysis": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "release_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "server_version": {
+ "type": "string"
+ },
+ "source_urls": {
+ "description": "Public URLs to cite.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "status": {
+ "enum": [
+ "ok",
+ "no_results",
+ "ambiguous",
+ "not_public",
+ "not_covered",
+ "source_unavailable",
+ "invalid_request"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "data",
+ "as_of",
+ "release_id",
+ "coverage",
+ "limitations",
+ "source_urls",
+ "links",
+ "server_version"
+ ],
+ "type": "object"
+}get_ip_market_snapshot1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "as_of": {
+ "description": "Generation time of the selected static release.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "coverage": {
+ "properties": {
+ "availability": {
+ "type": "string"
+ },
+ "error_type": {
+ "type": "string"
+ },
+ "exclusions": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "hold_state": {
+ "type": "string"
+ },
+ "jurisdiction": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "right_type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "static_assets": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "tier": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "data": {
+ "description": "Tool result. Which fields are present depends on status.",
+ "properties": {
+ "jurisdiction": {
+ "type": "string"
+ },
+ "leading_representatives": {
+ "items": {
+ "properties": {
+ "city": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "confidence_grade": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "home_country_code": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "profile_url": {
+ "type": "string"
+ },
+ "quoted_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "registration_rate": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "representative_id": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "score_tier": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "slug": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "time_to_grant_days": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "top_class": {
+ "type": [
+ "string",
+ "number",
+ "null"
+ ]
+ },
+ "volume_per_year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "message": {
+ "description": "Explanation when status is not ok.",
+ "type": "string"
+ },
+ "released_statistics": {
+ "type": "object"
+ },
+ "right_type": {
+ "type": "string"
+ },
+ "tier": {
+ "type": "string"
+ },
+ "window": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "limitations": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "links": {
+ "properties": {
+ "explore": {
+ "type": "string"
+ },
+ "methodology": {
+ "type": "string"
+ },
+ "request_analysis": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "release_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "server_version": {
+ "type": "string"
+ },
+ "source_urls": {
+ "description": "Public URLs to cite.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "status": {
+ "enum": [
+ "ok",
+ "no_results",
+ "ambiguous",
+ "not_public",
+ "not_covered",
+ "source_unavailable",
+ "invalid_request"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "data",
+ "as_of",
+ "release_id",
+ "coverage",
+ "limitations",
+ "source_urls",
+ "links",
+ "server_version"
+ ],
+ "type": "object"
+}get_ip_representative_profile1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "as_of": {
+ "description": "Generation time of the selected static release.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "coverage": {
+ "properties": {
+ "availability": {
+ "type": "string"
+ },
+ "error_type": {
+ "type": "string"
+ },
+ "exclusions": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "hold_state": {
+ "type": "string"
+ },
+ "jurisdiction": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "right_type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "static_assets": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "tier": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "data": {
+ "description": "Tool result. Which fields are present depends on status.",
+ "properties": {
+ "candidate_types": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "city": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "home_country_code": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "message": {
+ "description": "Explanation when status is not ok.",
+ "type": "string"
+ },
+ "profile_url": {
+ "type": "string"
+ },
+ "quoted_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "released_cohorts": {
+ "items": {
+ "properties": {
+ "jurisdiction": {
+ "type": "string"
+ },
+ "leading_clients": {
+ "items": {
+ "properties": {
+ "quoted_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "share_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "published_rating": {
+ "description": "Rating copied from the release: score, tier code (Q1 Elite to Q4 Select), confidence grade, rank.",
+ "properties": {
+ "confidence": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "score": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "tier": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "released_activity": {
+ "properties": {
+ "case_units": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "registration_rate": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "time_to_grant_days": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "total_firms_filing": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "volume_per_year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "right_type": {
+ "type": "string"
+ },
+ "tier": {
+ "type": "string"
+ },
+ "top_classes": {
+ "items": {
+ "properties": {
+ "class_code": {
+ "type": [
+ "string",
+ "number",
+ "null"
+ ]
+ },
+ "class_label": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "rank": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "share_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "window": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "representative_id": {
+ "type": "number"
+ },
+ "representative_type": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "text_provenance": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "limitations": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "links": {
+ "properties": {
+ "explore": {
+ "type": "string"
+ },
+ "methodology": {
+ "type": "string"
+ },
+ "request_analysis": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "release_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "server_version": {
+ "type": "string"
+ },
+ "source_urls": {
+ "description": "Public URLs to cite.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "status": {
+ "enum": [
+ "ok",
+ "no_results",
+ "ambiguous",
+ "not_public",
+ "not_covered",
+ "source_unavailable",
+ "invalid_request"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "data",
+ "as_of",
+ "release_id",
+ "coverage",
+ "limitations",
+ "source_urls",
+ "links",
+ "server_version"
+ ],
+ "type": "object"
+}get_iprate_coverage1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "as_of": {
+ "description": "Generation time of the selected static release.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "coverage": {
+ "properties": {
+ "availability": {
+ "type": "string"
+ },
+ "error_type": {
+ "type": "string"
+ },
+ "exclusions": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "hold_state": {
+ "type": "string"
+ },
+ "jurisdiction": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "right_type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "static_assets": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "tier": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "data": {
+ "description": "Tool result. Which fields are present depends on status.",
+ "properties": {
+ "cohorts": {
+ "items": {
+ "properties": {
+ "jurisdiction": {
+ "type": "string"
+ },
+ "published_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "right_type": {
+ "type": "string"
+ },
+ "run_id": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "status": {
+ "type": "string"
+ },
+ "tier": {
+ "type": "string"
+ },
+ "windows": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "hold_state": {
+ "type": "string"
+ },
+ "holdings": {
+ "type": "object"
+ },
+ "message": {
+ "description": "Explanation when status is not ok.",
+ "type": "string"
+ },
+ "published_profile_counts": {
+ "type": "object"
+ },
+ "supported_field_groups": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "limitations": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "links": {
+ "properties": {
+ "explore": {
+ "type": "string"
+ },
+ "methodology": {
+ "type": "string"
+ },
+ "request_analysis": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "release_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "server_version": {
+ "type": "string"
+ },
+ "source_urls": {
+ "description": "Public URLs to cite.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "status": {
+ "enum": [
+ "ok",
+ "no_results",
+ "ambiguous",
+ "not_public",
+ "not_covered",
+ "source_unavailable",
+ "invalid_request"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "data",
+ "as_of",
+ "release_id",
+ "coverage",
+ "limitations",
+ "source_urls",
+ "links",
+ "server_version"
+ ],
+ "type": "object"
+}searchfind_ip_representativesget_ip_market_snapshotget_ip_representative_profileget_iprate_coveragePatent search and company IP portfolio data
EPO/USPTO search, citations, OCR, plus PATSTAT Portfolio Analytics, guarded SQL and Graph Analytics.
AI-optimized patent data marketplace providing structured JSON datasets.
Global patent search, briefs, similarity, citations and landscape stats. Strong China coverage.
Add one secure layer between your agents and this server.