The InsideREU Model Context Protocol (MCP) server gives AI agents real-time access to European corporate insider trading disclosures (MAR Article 19). Query executive win-rate leaderboards, identify multi-insider cluster buys, and search for specific filings across 10 European jurisdictions directly from Claude Desktop, Cursor, or remote agents.
Scored across 4 tools
The four tools target distinct user intents: cluster signals, raw filing search, top-performer ranking, and individual insider lookup. There is minor conceptual overlap between get_track_record_ten and lookup_insider, but descriptions clarify the different purposes.
Three tools use a clean get_* prefix, while lookup_insider breaks the pattern slightly. Names are otherwise readable and predictable, though get_track_record_ten's 'ten' suffix is a minor inconsistency.
Four tools is an appropriate size for a focused, read-only insider-intelligence API. Each tool covers a distinct query type and earns its place with no obvious duplication.
The set covers raw filings, insider lookup, top-performer ranking, and cluster-buy signals, providing agents with workable core workflows. Missing sell-side cluster signals or company-specific activity endpoints are minor gaps rather than dead ends.
Get European companies where multiple corporate executives bought shares within the same time window (high conviction cluster buying signal).
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback window in days (default: 30, use 7 for past week) | |
| min_buyers | No | Minimum number of distinct corporate insiders buying (default: 2) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. It clearly conveys the core query behavior and the 'high conviction' interpretation, but it does not explain the data source, refresh characteristics, return shape, or exactly what counts as a purchase. This is a moderate, not severe, transparency gap for a read-oriented tool.
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 entire description is one front-loaded sentence with no filler. The parenthetical 'high conviction cluster buying signal' adds useful interpretive context without bloating the text.
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 low-complexity tool with two optional, fully documented parameters and no output schema, the description gives enough context to select and invoke it correctly. It names the returned resource and the core filter; mentioning ordering or result limits would improve completeness but is not essential.
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 both parameters (days and min_buyers) are already documented with defaults and meaning. The description reinforces the cluster idea but adds no parameter-level detail such as how days and min_buyers interact, so it stays at the baseline.
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 uses a concrete verb ('Get') and identifies the exact resource: European companies exhibiting multiple insider buys in a shared time window. This distinguishes it from sibling tools like get_recent_filings or lookup_insider, which serve different purposes.
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 it (when the agent needs a cluster-buying signal), but it never explicitly contrasts it with the sibling tools or states when to prefer another tool. There are no exclusion conditions or alternative references, so the guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and filter recent European corporate insider transaction disclosures (director dealings / MAR Article 19).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of filings to return (default: 10, max: 50) | |
| country | No | Optional ISO-2 country code (e.g. DE, SE, FR, UK, CH, NO, IT, ES, NL, BE) | |
| min_value_eur | No | Minimum transaction value in EUR (e.g. 50000) | |
| transaction_type | No | Transaction type (default: buy) | buy |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states the purpose; it does not mention read-only nature, return format, pagination, or any limitations. This is insufficient for a tool with no annotations.
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 efficiently conveys the tool's purpose without unnecessary words.
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 4 parameters, no output schema, and no annotations, the description is too sparse. It doesn't explain what the response looks like, any constraints (e.g., date range implied by 'recent'), or how to interpret the results. This is inadequate for an agent to use the tool confidently.
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. The description adds domain context (insider transactions) that helps interpret parameters, but it doesn't detail parameter-specific semantics beyond what the schema provides.
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 function: searching and filtering recent European insider transaction disclosures, with specific domain context (director dealings, MAR Article 19). However, it does not explicitly differentiate from sibling tools like get_cluster_buys or lookup_insider, so it falls 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?
The description provides no guidance on when to use this tool versus its siblings. There is no mention of scenarios, alternatives, or exclusions. The agent is left to infer 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.
Get the 10 European corporate insiders with the highest 12-month win rates and average returns on their personal stock purchases (The European 'Pelosi-equivalent' tracker).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. While 'Get' implies a read-only operation, it does not mention whether data is real-time, if pagination exists, or how 'win rate' is calculated. No side effects, data freshness, or limitations are disclosed.
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 conveys the core action and criteria efficiently. The parenthetical adds a useful analogy without excessive verbosity, though it is not 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?
For a zero-parameter tool with no output schema, the description states what is returned but omits important details such as the exact fields in the result, ordering, or any caveats about data availability. An agent could call the tool correctly, but might not fully know what format to expect.
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 is empty (0 parameters), so schema description coverage is 100%. The description adds context about the result selection criteria but does not need to explain parameters; the baseline of 4 for zero-parameter tools 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 clearly states a specific verb ('Get'), a resource ('European corporate insiders'), and precise criteria ('10 ... highest 12-month win rates and average returns'), making it easy to distinguish from sibling tools like get_cluster_buys or get_recent_filings. The parenthetical 'Pelosi-equivalent tracker' adds useful context without ambiguity.
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 no explicit guidance on when to use this tool over the sibling tools. It does not mention alternatives, exclusions, or conditions under which this tool is preferred, leaving the agent to infer its use case solely from the stated output.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a specific European corporate insider by their insider ID or executive name to view their disclosed transactions, company affiliations, and performance.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Insider ID (slug) or executive name to search |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must carry the burden of behavioral disclosure. It mentions the purpose but does not disclose any behavioral limitations, such as whether the search is exact or fuzzy, what happens if no insider is found, or if the query is case-sensitive. The description does not contradict annotations (none provided), but it under-discloses.
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 concise and front-loaded with the purpose, then lists what information is available (transactions, affiliations, performance). It is efficient without waste, though it could be slightly more structured for readability.
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 one parameter and no output schema, the description is moderately complete. It tells the agent what to input and what it returns, but it lacks details on edge cases, such as how the 'slug' works or how to handle ambiguous names. It also does not mention potential errors or limitations, which would help an agent decide if this is the right tool.
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%, so the query parameter is fully described in the schema. The description adds context that the query can be either an ID or name, which adds some meaning beyond the schema's 'search', but it does not add syntax or format details. Baseline 3 is appropriate.
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 clear purpose: to look up a European corporate insider by ID or name and view their disclosed transactions, affiliations, and performance. It effectively distinguishes itself from sibling tools like get_cluster_buys and get_recent_filings by focusing on a specific insider entity.
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 that this tool is used when you need information on a specific insider, but it does not explicitly state when to use it versus alternatives like get_cluster_buys. It lacks explicit 'when not to use' guidance, which is a gap given the sibling tools could be alternatives.
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_cluster_buysget_recent_filingsget_track_record_tenlookup_insider
Add one secure layer between your agents and this server.