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 10 tools
Most tools have distinct purposes, but get_radar_pro_alerts and get_rebound_panics both cover 'disaster buys / market overreactions', and get_daily_briefing re-aggregates data (insider buys, Rebound Radar drops, own trades) already available via other tools. The portfolio tools (track_trade, close_trade, list_my_trades) are cleanly separated, but the signal-feed tools have fuzzy boundaries.
Nearly all names use consistent snake_case verb_noun form (get_cluster_buys, list_my_trades, close_trade). The 'get_' prefix appears frequently, while a few tools use different verbs (track, lookup, list), which is minor but not confusing. No camelCase/snake_case mixing.
10 tools is well-scoped for the domain: six signal/lookup tools plus three portfolio-management tools and one aggregator briefing. Each tool appears to earn its place with no obvious redundancy padding the count.
The surface covers the core lifecycle of insider-intelligence (filings, cluster buys, radar alerts, insider lookup, track record) plus portfolio management (track/list/close). Minor gaps exist: no update/edit for a saved trade and no direct 'get single trade by id' detail beyond the list, but agents can work around these.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the auth requirement ('Requires an InsideREU API key') and implies a mutation, but says nothing about reversibility, whether the trade leaves the tracked list after closing, whether closing twice errors, or what the call returns.
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, zero filler: action and scope first, identification method second, prerequisite third. Every clause earns its place and nothing is buried.
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 4-param mutation tool with no annotations, no output schema, and 50% schema coverage, the description covers identification and auth but leaves lifecycle questions unanswered — what state the trade ends in, currency handling, and error behavior on unknown ticker or duplicate close.
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 50% (ticker and company_name are undocumented in the schema). The description compensates by clarifying that trade_id, ticker, and company_name are alternative identifiers for the same trade — OR semantics the schema's flat optional-string list 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?
States a specific verb and resource — 'Record the exit of one of YOUR tracked trades (sold / took profit)' — which clearly distinguishes it from track_trade (entry) and list_my_trades (read). It does not, however, name the sibling tools explicitly, so the differentiation is inferred rather than stated.
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 possessive 'YOUR tracked trades' implies a prerequisite (the trade must already exist via track_trade) and the description offers alternative identification paths. But it never states when to prefer this over track_trade or list_my_trades, and no exclusions (e.g., 'do not use to open positions') are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose meaningful traits: results are ranked, noise-filtered, and the trade review uses 45/90-day windows, plus it signals a personal/auth-scoped view ('the caller's own trades') and appends a non-advice disclaimer. It stops short of stating read-only status explicitly, freshness/timezone of 'the day', or any rate/permission requirements.
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?
A single front-loaded sentence enumerating the three payload sections, followed by a short disclaimer. No filler, no repetition of the title or name.
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 no output schema and no annotations, the description usefully enumerates what comes back, which is the key missing structured information. Minor gaps remain around the definition of 'the day' and whether the briefing is user-scoped, but nothing blocks a correct call.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No parameter syntax or defaults are needed.
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+resource (a daily briefing) and enumerates exactly what it aggregates: ranked insider buys, Rebound Radar price drops, and the caller's own trades due for review. This enumeration maps directly onto the sibling tools (lookup_insider/get_cluster_buys, get_rebound_panics, list_my_trades), making the composite scope distinguishable without opening any schema.
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 'in one call' implies this is the aggregate alternative to calling the individual sibling tools, which gives implied usage context. However, it never states when to prefer this over get_rebound_panics or list_my_trades, nor any exclusion such as freshness or date-scope limits. Usage is inferable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does disclose the auth/plan requirement, which is genuine behavioral context beyond the schema. However, it says nothing about return shape, freshness window, rate limits, or what 'recent' means, leaving meaningful gaps for a tool with no annotations or output schema.
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 short sentences, front-loaded with the purpose and followed by the only operative constraint. No filler or restatement of the tool name.
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-param, no-output-schema tool, the description covers what is retrieved and the access precondition, which is enough to invoke it correctly. It stops short of characterizing the alert payload (fields, window, volume), which the absent output schema would otherwise have to cover.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool 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?
Names a specific verb (Get) and resource (Radar Pro disaster buys / market overreactions), which is clearer than a generic 'alerts' label. It does not, however, explicitly distinguish itself from thematic siblings like get_rebound_panics or get_cluster_buys, so the agent must infer the difference.
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 supplies a real prerequisite — an InsideREU API key on a trial or paid plan — which tells the agent when the call will succeed. It gives no guidance on when to prefer this over sibling alert/panic tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden, yet it only frames the data domain (European, MAR Article 19). It says nothing about return format, ordering, pagination limits beyond the schema's own 'max 50', whether results are cached or rate-limited, or what happens when filters match nothing.
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?
A single front-loaded sentence with no filler; the core verb and resource lead, and the clarifying parenthetical is compact. Nothing wastes space.
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 five-parameter search tool with no annotations and no output schema, the description is thin: it never indicates what a returned filing contains (issuer, insider role, value, date) or how results are ordered. The rich parameter schema partly compensates, but the definition is only minimally adequate.
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 all five parameters (limit, country, include_noise, min_value_eur, transaction_type) are already well documented in the schema, including defaults and the meaning of include_noise. The description adds no parameter meaning beyond the schema, which is the expected baseline of 3 at full coverage.
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 gives a specific verb ('Search and filter') and a well-defined resource ('recent European corporate insider transaction disclosures'), with the parenthetical clarifying these are MAR Article 19 director dealings. It does not differentiate itself from siblings like lookup_insider or get_cluster_buys, which an agent would need to distinguish this from.
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?
There is no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as lookup_insider or get_cluster_buys. The word 'recent' implies a recency scope but offers no routing logic for an agent choosing among nine sibling tools.
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.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses an authentication requirement ('InsideREU API key') and some return fields, and 'List' implies a read-only operation. It does not clarify pagination, rate limits, or whether any side effects occur, leaving meaningful gaps for a no-annotation 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 description is two short sentences with no waste. The primary listing behavior is front-loaded, and the authentication constraint follows directly, making it easy to scan.
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 simple one-parameter list tool with no output schema, the description gives the core purpose, an auth requirement, and a summary of returned fields. It could say more about ordering or pagination, but it is largely sufficient for correct invocation.
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 single optional 'status' enum parameter is already fully documented in the schema. The description adds no parameter-specific meaning such as what 'open', 'closed', or 'all' return, so the 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 specific verb ('List') and resource ('YOUR tracked trades'), and it names several returned fields. It is clearly distinguishable from sibling mutation tools like track_trade and close_trade, but it does not explicitly contrast itself with any alternative, keeping it below 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?
Usage is implied by 'List YOUR tracked trades' and the prerequisite 'Requires an InsideREU API key' is useful. However, there is no explicit guidance on when to use this tool versus siblings such as track_trade or get_track_record_ten, nor any exclusions or conditions.
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.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so notably well: it discloses a non-obvious side effect (review reminder emails at 45 and 90 days, and at +10%) and an auth requirement ('Requires an InsideREU API key'). It omits rate limits and return behavior, keeping it short of a 5.
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, front-loaded with the core action before the behavioral details. Every clause earns its place, though the real/paper parenthetical slightly duplicates the schema's kind description.
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 an 8-parameter save tool with full schema documentation and no output schema, the description supplies the crucial behavioral facts an agent needs (email side effects, API-key auth). It is fairly complete, with only response/confirmation behavior left unstated.
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 all eight parameters including the kind enum and currency defaults. The description only echoes the real/paper choice and adds no format or syntax detail beyond the schema, which is the baseline 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?
States a specific verb and resource ('Save a trade to YOUR portfolio') and immediately clarifies the real-vs-paper distinction. An agent can distinguish this write/save operation from read siblings like list_my_trades and from the state-changing close_trade.
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?
It gives a selection condition for the real/paper choice ('the user says they bought it' = real), which is useful. But it says nothing about when to prefer this over siblings such as close_trade, and offers no prerequisites or exclusion conditions.
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.
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.