Real-Time Patent Litigation & Docket Intelligence Across Europe - UPC-Intel - provides programmatic Model Context Protocol (MCP) access to active European patent litigation proceedings across all 6 key jurisdictions:
Unified Patent Court (UPC
UK High Court
EPO Boards of Appeal
Swiss Federal Patent Court
Spanish Commercial Courts
Warswaw District IP Court
Scored across 4 tools
Each tool targets a distinct resource: a specific case, a judge, a patent, or a docket search. Although patent risk and docket search can both surface active proceedings, their intents (analysis vs search) are clearly differentiated.
All tool names follow a consistent snake_case get_/search_ + noun pattern, making the operation and resource predictable from the name alone.
Four focused tools are well-scoped for a specialized European patent litigation intelligence server; each fills a distinct role without redundancy or bloat.
The set covers the core read-only workflow: search for proceedings, retrieve case intelligence, check patent risk posture, and benchmark judges. Minor gaps such as raw docket timelines or party-specific filters are workable via existing tools.
Retrieve comprehensive strategic docket intelligence for a specific European patent case: plain-English executive holding, litigator practice pointer, cross-border multi-front exposure matrix, and judge analytics.
| Name | Required | Description | Default |
|---|---|---|---|
| case_number | Yes | The case docket number e.g. 'UPC_CFI_1/2023', '[2026] EWHC 2235 (Pat)', 'BPatG O2025/005', 'ECLI:ES:APB:2026:1420' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden. It transparently states what is retrieved and lists the output components, which covers the tool's read-oriented behavior. However, it does not mention any permissions, latency, error conditions, or limitations – areas that remain opaque for a tool with 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action and resource before enumerating components in a colon-separated list. It is concise without losing substance, though slightly longer than strictly necessary.
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 has no output schema, the description compensates by listing the key output elements (executive holding, practice pointer, cross-border matrix, judge analytics). It gives the agent a solid expectation of what will be returned. It does not detail data format or interpretation, but for a single-parameter 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 coverage is 100% and the schema already gives detailed examples for case_number. The description adds no parameter-specific meaning beyond the context 'specific European patent case', which is consistent but not additive. 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 opens with a specific verb ('Retrieve') and a clear resource ('comprehensive strategic docket intelligence') for a defined scope ('specific European patent case'), then enumerates the deliverables. This distinguishes it from siblings like search_european_dockets (search vs. specific case) and get_judge_benchmarks (subset of the analytics).
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 phrase 'for a specific European patent case' clearly implies the tool is for when the agent already has a case number, not for discovery. Context signals and sibling names reinforce this, but the description does not explicitly name alternatives or conditions. Clear context, no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get empirical judicial intelligence on European patent judges: median days to preliminary injunction, grant rate propensity, language breakdown, and known bench tendencies.
| Name | Required | Description | Default |
|---|---|---|---|
| judge_name | Yes | Full or partial judge name e.g. 'Zigann', 'Grabinski', 'Meade', 'Thomas' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Get' implies a read-only operation, and the listed output fields describe what the agent will receive. However, it does not explicitly state non-destructiveness, data source, or any limitations, leaving some ambiguity about side effects and scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that leads with the tool's purpose and then lists specific output data in a clear colon-delimited series. There is no filler or redundancy; 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?
For a single-parameter tool with no output schema, the description adequately covers what the agent needs to know: the output fields are enumerated. It does not cover potential edge cases like partial-name matching limitations or error conditions, but the schema and examples handle the input side, so the definition is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the judge_name parameter already includes format examples and partial-match guidance. The tool description does not add parameter-level detail, so it does not exceed the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('Get') and resource ('empirical judicial intelligence on European patent judges'), then enumerates concrete output metrics (median days to preliminary injunction, grant rate propensity, language breakdown, known bench tendencies). This clearly distinguishes the tool from siblings like get_case_intelligence or get_patent_asset_risk, which focus on different entities.
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 gives clear context: use this tool when you need judge-specific empirical benchmarks, such as median PI timelines or grant rates. It does not explicitly name alternatives or exclusions, but the specificity of the output fields makes the appropriate usage evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze the European litigation posture of a specific patent: Unitary Patent (UP) status, opt-out risk, SEP/FRAND classification, and all active proceedings across the UPC, UK, EPO, and national courts.
| Name | Required | Description | Default |
|---|---|---|---|
| patent_number | Yes | European patent number e.g. 'EP3883351' or 'EP2154874' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly indicates this is an analysis operation (not a mutation) and lists the analytical dimensions covered. However, it does not disclose whether the data is live, cached, or whether any external dependencies exist (e.g., docket API availability). It also doesn't mention any limitations such as patent coverage by jurisdiction, which could affect results. The description is functional but not deeply transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose ('Analyze the European litigation posture of a specific patent') before enumerating the detailed aspects. Every word adds value, with no filler or repetition. It is concise and effective.
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 there is no output schema, the description must convey what the tool returns. It enumerates the key analysis areas (UP status, opt-out risk, SEP/FRAND classification, active proceedings across courts), which gives a solid picture of the output scope. However, it does not mention the structure or format of the returned data (e.g., whether it's a summary object, list of proceedings, etc.), which could leave an agent unsure about how to consume the result. This is a minor gap in an otherwise comprehensive description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the single parameter with a clear description and example ('EP3883351' or 'EP2154874'). The description itself does not add additional parameter semantics beyond what the schema already provides, which meets the baseline for full schema coverage. No extra context is given for parameter format, but the schema is sufficient.
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 ('Analyze'), a specific resource ('a specific patent'), and enumerates the exact scope (UP status, opt-out risk, SEP/FRAND classification, active proceedings across UPC, UK, EPO, national courts). It clearly distinguishes itself from siblings like get_case_intelligence (focused on case details), get_judge_benchmarks (judge analytics), and search_european_dockets (search across dockets).
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 its use case (analyzing a patent's European litigation posture) but does not explicitly state when to prefer this over siblings, nor when not to use it. There are no alternative tool names mentioned, so the agent must infer selection based on the described scope, which is reasonably clear but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search active European patent litigation proceedings across the Unified Patent Court (17 states), UK High Court (London Patents Court), EPO Boards of Appeal (Munich), Swiss Federal Patent Court (BPatG St. Gallen), Spanish Commercial Courts, and Warsaw IP Court. Query by patent number, entity name, or keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default: 10) | |
| query | Yes | Search term e.g. 'EP 3 883 351', 'Sanofi', 'preliminary injunction', 'FRAND', 'Samsung' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool searches 'active' proceedings, which sets a scope constraint, and lists the courts covered. However, it does not disclose whether the operation is read-only, how results are returned (list, fields, pagination), or any limitations such as date ranges or filtering. The description gives some useful context but lacks depth on behavior beyond the query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and resource, then lists the courts. It is efficient but slightly long due to the enumeration of six courts; however, that detail is valuable for an agent deciding whether this tool matches the jurisdiction. No wasted words, and the query examples are included in the schema rather than repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should give some indication of what results look like. It explains what is searched (active proceedings across specific courts) but does not mention what fields are returned (e.g., case number, court, status, date) or any ordering/pagination behavior. For a search tool with moderate complexity and no output schema, this is a notable gap. The 'active' constraint is helpful, but the missing return information leaves the agent uncertain about how to use the 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?
The input schema has 100% coverage: both 'query' and 'limit' have descriptions with examples. The description adds a small amount of extra meaning by stating 'Query by patent number, entity name, or keyword', which reinforces the query parameter's intent but does not go beyond what the schema already illustrates. Since schema coverage is high, a baseline of 3 is appropriate; the description provides marginal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to search active European patent litigation proceedings across a specific set of courts. It names the exact verb 'search', the resource 'patent litigation proceedings', and enumerates the jurisdictions (UPC, UK High Court, EPO Boards of Appeal, etc.), which makes it distinct from sibling tools that retrieve specific case intelligence, judge benchmarks, or patent asset risk. This is a precise, non-tautological statement.
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 when to use this tool (when you need to search litigation across European courts) but does not explicitly contrast it with sibling tools like get_case_intelligence or get_judge_benchmarks. It provides no 'use this instead of X' guidance or exclusions. The intended use is clear from the context, but there's no explicit routing.
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.
get_case_intelligenceget_judge_benchmarksget_patent_asset_risksearch_european_dockets
Add one secure layer between your agents and this server.