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 8 tools
Most tools target distinct signals or resources, but get_radar_pro_alerts and get_rebound_panics both cover market overreaction/disaster-buy concepts and could be confused. get_cluster_buys and get_recent_filings are also related, though the descriptions distinguish cluster signals from raw filing search.
All tool names use snake_case and follow a verb_noun pattern (get_*, lookup_insider, track_paper_trade). The variation in verb choice is semantic rather than inconsistent, and the names are readable and predictable.
Eight tools is well-scoped for a niche insider-trading intelligence server. Each tool has a clear purpose and the set avoids both thinness and excessive surface area.
The server covers several useful signal and lookup workflows, but the paper-trade lifecycle is incomplete: it supports creating a paper trade but not listing, reading, updating, or closing tracked paper trades. This is a notable gap for the portfolio-tracking portion of the domain.
Record the exit of one of YOUR tracked trades (sold / took profit). Identify it by trade_id, or by ticker / company name. Requires an InsideREU API key.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | No | ||
| trade_id | No | id from list_my_trades (preferred) | |
| exit_price | Yes | Price per share you sold at, in the trade's currency. | |
| company_name | No |
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.
The day's highlights in one call: top insider buys (ranked, noise filtered), sudden price drops from Rebound Radar, and the caller's own trades due a 45/90-day review. Information only, not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Get recent Radar Pro disaster buys / market overreactions to track. Requires an InsideREU API key on a trial or paid plan.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Get today's Rebound Radar alerts. These are global blue-chip stocks that dropped >5% on volume and were evaluated by GPT-4 for overreactions. Use this to find 'ACUTE_SHOCK' or 'OPERATIONAL_FRICTION' buying opportunities.
| Name | Required | Description | Default |
|---|---|---|---|
| playbook | No | Optional filter by GPT-4 classified playbook. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose meaningful behavior: the data is scoped to today, the universe is global blue-chip names, and inclusion requires a >5% volume-backed drop plus GPT-4 overreaction classification. It does not say anything about result size, ordering, freshness beyond 'today', or permissions, so the behavioral picture is partial.
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 short sentences, front-loaded with the core action and with no filler. The middle sentence is dense but earns its place by defining the alert criteria; overall tight and readable.
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-optional-param read tool with no output schema, the description covers what the data is, how it was generated, and how to use it. The main remaining gap is the shape and volume of the returned alerts, which an agent would have to discover by calling it.
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 single optional param already carries its own description, so the schema does the heavy lifting. The description adds the framing that the two enum values are buying-opportunity categories, which is mild extra meaning but not new filtering semantics such as what happens when the filter is omitted.
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 ('Get today's Rebound Radar alerts') and goes further by defining what the alerts actually are: global blue-chip stocks that dropped >5% on volume and were GPT-4 evaluated. That makes the tool's domain concrete, though it never names or distinguishes itself from the similarly-named sibling get_radar_pro_alerts or get_cluster_buys.
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 to find ACUTE_SHOCK or OPERATIONAL_FRICTION buying opportunities' gives a clear context for when to reach for this tool and ties it to the enum values. There are no stated exclusions or routing rules against the other alert-style siblings, so it stops short of full alternative guidance.
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) | |
| include_noise | No | Include employee share plans, share issues and holding/group-entity filers (default: false = open-market purchases by individuals only) | |
| min_value_eur | No | Minimum transaction value in EUR (e.g. 50000) | |
| transaction_type | No | Transaction type (default: buy) | buy |
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.
List YOUR tracked trades with amount, days held / left, latest price and return where available. Requires an InsideREU API key.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Default open. |
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.
Save a trade to YOUR portfolio, real (the user says they bought it) or paper. Sends review reminders by email at 45 and 90 days, and when it is up 10%. Requires an InsideREU API key.
| Name | Required | Description | Default |
|---|---|---|---|
| isin | No | ISIN, if known | |
| kind | No | 'real' if the user actually bought it, 'paper' for a hypothetical trade. Default paper. | |
| amount | No | Total money invested, in `currency` (e.g. 10 for 'I put in 10 GBP'). | |
| ticker | No | Local ticker symbol (e.g. EVD). Strongly recommended: needed for price tracking. | |
| currency | No | ISO currency of entry_price and amount (EUR, GBP, SEK...). Default EUR. | |
| exchange | No | Exchange symbol | |
| entry_price | No | Price per share you paid, in `currency`. If omitted, the latest known EUR price is used when available. | |
| company_name | Yes | Name of the company |
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
close_tradelist_my_tradestrack_paper_tradetrack_tradeget_recent_filings1 field changedInput schema / properties / include_noiseAdded value: +{
+ "default": false,
+ "description": "Include employee share plans, share issues and holding/group-entity filers (default: false = open-market purchases by individuals only)",
+ "type": "boolean"
+}get_radar_pro_alertsget_rebound_panicsget_daily_briefingtrack_paper_tradeget_cluster_buysget_recent_filingsget_track_record_tenlookup_insider
Add one secure layer between your agents and this server.