Source-backed US market signals: insider filings, Congress trades, institutions, consensus.
Scored across 16 tools
Most tools target distinct resources (trades lists, positioning, screening, ticker search), and descriptions actively steer agents (e.g. get_demo_composite vs get_composite, screen vs rank_consensus). The main overlap is among the single-ticker views — get_composite, get_consensus, and get_house_rating all answer 'what do we think of this name' — but the documented distinctions (superset record vs agreement verdict vs proprietary rating) keep them separable.
Consistent get_*/list_* verb_noun snake_case throughout, with rank_consensus, search_tickers, and screen as readable single-verb discovery tools. No camelCase mixing or vague verbs.
16 tools is on the heavier side but each maps to a genuinely different data source or operation (composite, consensus, evidence, perp funding, historic moves, rating, activity, macro signal, congress, insider, COT positioning, screening, ranking, search). Nothing feels redundant or filler.
Strong coverage of the market-intelligence lifecycle: discovery (screen, rank_consensus, search_tickers), per-name deep dives (composite, consensus, evidence, historic_moves, house_rating), market-wide context (get_signal, list_positioning, list_equity_perp), and flow (congress, insider, monthly_activity). Minor gaps like watchlists/alerts or per-ticker congressional linkage exist but core workflows have no dead ends.
Everything the platform knows about one ticker in a single record: the cross-signal consensus, each contributing dimension with its direction and provenance, and risk flags. Start here for any question about a specific company.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Ticker symbol, e.g. AAPL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to repeat safety. It adds useful content context (records contain consensus, dimensions, provenance, risk flags) but does not disclose behavior like data freshness, latency, or how missing tickers are handled. No contradiction with 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?
Two concise sentences that front-load the core value ('Everything the platform knows about one ticker in a single record') and end with a clear usage directive. No filler or redundancy.
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 read tool without an output schema, the description adequately explains the record's composition and offers guidance on when to use it. It could be slightly more complete by specifying return type or error behavior, but the current content is largely sufficient given its simplicity.
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%--the single parameter 'ticker' is described with an example (AAPL). The description does not add further parameter semantics beyond the schema, so 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 uses a specific verb ('get') and clearly identifies the resource ('composite signal for a ticker'). It enumerates what the record contains (cross-signal consensus, contributing dimensions, provenance, risk flags) and differentiates from siblings like get_consensus by framing it as the comprehensive 'everything' endpoint.
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 'Start here for any question about a specific company,' signaling a clear use case. While it does not explicitly mention when to use sibling tools instead, the 'start here' instruction implies a first-stop role and provides enough context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Whether the independent actors this platform tracks — insiders, Congress, institutions, the model — agree on one ticker, with the per-dimension breakdown that produced the verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Ticker symbol, e.g. AAPL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already provided by annotations, the description adds context by explaining what 'consensus' means (agreement among insiders, Congress, institutions, the model) and that a per-dimension breakdown is included. It does not introduce contradictions and provides meaningful behavioral context beyond the annotation.
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, concise sentence that front-loads the core purpose and uses no wasted words. It clearly communicates the tool's function and output in an efficient manner.
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 one required parameter, a read-only annotation, and no output schema, the description adequately conveys what the tool does and what it returns. It could specify exact response fields, but the high-level 'verdict and per-dimension breakdown' is sufficient for an agent to understand the tool's behavior.
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 fully describes the only parameter (ticker symbol, e.g., AAPL) with 100% coverage. The description adds no additional parameter-specific semantics, so the baseline score of 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 clearly states the tool's purpose: checking whether independent actors (insiders, Congress, institutions, the model) agree on a single ticker, and it mentions the per-dimension breakdown. This distinguishes it from siblings like rank_consensus (which likely ranks across tickers) and get_signal (which likely returns a single signal).
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 for a single ticker through 'on one ticker,' but it does not explicitly state when to use this tool versus alternatives like rank_consensus or get_signal, nor does it provide exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A single fixed demo ticker, callable without an API key, so the data shape can be inspected before signing up. Returns only the demo ticker regardless of input. For real tickers use get_composite, which requires a free key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals safety, but the description adds unique behavioral context: no API key required and output is always the demo ticker regardless of input. This goes beyond what annotations provide, though it doesn't detail rate limits or return format.
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 concise sentences, each earning its place: purpose, behavior, and alternative. Information is front-loaded with the most important facts first, zero fluff.
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 tool with no parameters and no output schema, the description fully covers what the agent needs to know: what it returns (demo ticker), why (inspect data shape), auth constraints (no key), and how it differs from the real tool. No gaps.
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?
With zero parameters, the baseline is 4. The description adds value by explaining that input is irrelevant ('regardless of input'), which preempts any attempt to pass a ticker. Given the empty schema, this semantic clarification is helpful.
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 clearly defines the tool as a fixed demo ticker for inspecting data shape, with the specific goal of pre-signup exploration. It explicitly distinguishes from get_composite for real tickers, satisfying the 'specific verb+resource+scope' criterion.
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 when to use (before signing up) and when not (for real tickers), and names the alternative tool get_composite. This provides clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Funding and open interest for a single name on the 24/7 perpetual venue. Most tickers are NOT listed there — only about 51 of about 4,600 covered tickers — and a 'not listed' answer means no venue coverage, never that positioning is flat or zero.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Ticker symbol, e.g. AAPL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true; the description adds genuinely non-obvious behavioral semantics — the sparse coverage set and the crucial distinction that 'not listed' means no venue coverage rather than flat/zero positioning. This is exactly the kind of context annotations cannot convey, though it does not describe response fields or freshness.
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, zero waste, with the core capability front-loaded and the coverage caveat immediately after. Every sentence 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?
No output schema exists, but the description summarizes what is returned (funding, open interest) and the key pitfall, so an agent can call it correctly. Only minor omissions remain, such as field details or update frequency.
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% for the single ticker parameter, so the schema already documents it fully. The description adds no syntax, format, or constraint detail beyond what the schema provides; 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+resource: funding and open interest for a single ticker on the 24/7 perpetual venue. This clearly distinguishes it from siblings like list_equity_perp (enumerating names) and list_positioning, which an agent can differentiate without opening schemas.
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?
Gives strong when-to-use context by warning that most tickers are NOT listed (only ~51 of ~4,600) and reading a 'not listed' answer correctly. It stops short of naming an alternative tool to use instead, so it is clear context without explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid key required. The primary documents a ticker's signals were derived from — insider Form 4s, institutional holdings and macro series, with the filing each came from where one is available. Use this to cite a claim rather than assert it. Paid keys are not on sale yet. A ticker whose evidence has not been published yet returns evidence_not_published. Congressional trades are not included: use list_congress_trades, which works on every key.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Ticker symbol, e.g. AAPL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds real behavioral context beyond that: a paid key is required and not yet on sale, unpublished tickers return evidence_not_published, and congressional-trade coverage is explicitly excluded. It could go further on return shape (e.g., volume or pagination of documents), but the access and failure-mode disclosures are genuinely useful.
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?
Well front-loaded: access requirement first, then what is returned, then the usage rationale, then the exclusion. Nearly every sentence earns its place, though the 'not on sale yet' remark and the redirect form a slightly dense closing run.
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?
No output schema exists, yet the description still conveys return contents (source documents plus originating filing), the not-published error case, coverage limits, and the key requirement. An agent has everything needed to decide and call correctly.
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?
With one parameter at 100% schema description coverage, the schema already documents 'ticker' with an example, so the baseline is 3. The description adds only indirect parameter behavior — the evidence_not_published outcome for tickers without published evidence — and no format or normalization guidance.
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: it returns the primary source documents (Form 4s, institutional holdings, macro series) behind a ticker's signals, with the originating filing where available. That is far more specific than the sibling list tools and lets an agent tell it apart without opening a 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?
Gives an explicit rationale ('use this to cite a claim rather than assert it') plus a concrete exclusion and redirect: congressional trades are not included, use list_congress_trades instead, which works on every key. Access conditions (paid key required, not yet on sale) are also stated up front.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The historical distribution of 5-day and 1-month returns for a ticker, sampled over the last 5 years: mean, standard deviation, percentiles, a histogram, and the worst drawdowns with their dates. Use it to say whether a move is unusual FOR THIS NAME rather than in the abstract. Every number is a fraction: 0.0821 means 8.21%.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Ticker symbol, e.g. AAPL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds valuable behavioral context beyond that: it details the exact statistical outputs, clarifies the 5-year sampling window, and warns that values are fractional (0.0821 means 8.21%). This helps the agent interpret results correctly without contradicting the read-only hint.
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 three sentences long and every sentence earns its place: listing the outputs, stating the use case, and explaining the fractional notation. No extraneous words or repetition of the name/title.
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 read-only tool with one parameter and no output schema, the description is complete: it enumerates the returned metrics, states the historical window, and explains the value format. It provides enough context for an agent to know what to expect and when to use it, without needing an output schema.
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% for the single ticker parameter, which already explains it clearly. The description does not add further parameter semantics, but it doesn't need to. Baseline 3 is appropriate since the schema fully covers the parameter.
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 what the tool does: provides the historical distribution of 5-day and 1-month returns for a ticker over the last 5 years, including mean, standard deviation, percentiles, histogram, and worst drawdowns. It also explicitly frames its purpose ('whether a move is unusual FOR THIS NAME'), distinguishing it from generic market analysis tools like get_composite or get_signal.
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 usage context: 'Use it to say whether a move is unusual FOR THIS NAME rather than in the abstract.' This implies the tool is for ticker-specific historical comparison, but it doesn't explicitly mention when not to use it or name alternative sibling tools. The guidance is sufficient for most intended scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid key required. The platform's own buy/hold/sell rating for a ticker, with the reasoning behind it. A judgement about the stock, not a recommendation to any reader. Paid keys are not on sale yet.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Ticker symbol, e.g. AAPL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true; the description adds meaningful context beyond that: a paid key is required, paid keys are not yet available, and the output is an opinion rather than advice. These are genuine behavioral facts not present in structured fields.
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 with the gating requirement ('Paid key required') front-loaded. Efficient, though the 'not a recommendation' and 'not on sale yet' clauses are somewhat tangential to invoking the tool.
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 read tool with no output schema, the description covers the auth gate and the interpretive nature of the result. The main omission is any guidance on choosing this tool over sibling rating tools.
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 single parameter is fully documented in the schema, so baseline 3 applies. The description adds no format or syntax detail beyond what the schema already 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?
States a specific resource (the platform's own buy/hold/sell rating for a ticker) and the verb-equivalent ('get'), and clarifies it includes the reasoning behind it. It does not explicitly distinguish itself from siblings like get_composite or get_consensus, 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?
Provides a key prerequisite ('Paid key required') and frames the output's nature ('A judgement about the stock, not a recommendation'), which helps set expectations. However, it never says when to use this versus the many sibling rating/consensus tools, leaving selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank ticker activity aggregated from available published filings by transaction date for the current UTC month through today. Includes coverage metadata and unknown-value counts; this is not total market activity. Congress: 10 names on every customer key. Insiders: free keys receive up to 10 names, paid keys up to 20.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Which published filing activity to aggregate. | |
| month | No | Optional YYYY-MM; only the current UTC month is supported. Defaults to the current UTC month. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, so safety is covered. The description adds important behavioral nuances: it covers only current UTC month, includes coverage metadata and unknown-value counts, and has tier-specific limits (10 names for congress, 10/20 for insiders based on key type). This goes beyond the schema and helps set expectations.
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 three sentences, front-loaded with the core purpose and scope, then adds caveats and tier details. Every sentence adds value without redundancy.
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 moderate complexity (ranked output with metadata and limits) and no output schema, the description covers the essential behavioral aspects. It could optionally specify whether results are sorted descending or include a date range, but the core usage is clear.
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%: both 'kind' and 'month' have descriptions with enums and default behavior. The description does not add much beyond reinforcing the month validity and tier limits, so 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 clearly states the tool aggregates and ranks ticker activity from published filings for the current UTC month, with a specific resource (filings) and a clear distinction from sibling tools like list_congress_trades or list_insider_trades which likely list raw trades. It also disambiguates scope (current month) and adds a caveat that it's not total market activity.
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 for ranked, aggregated monthly activity rather than raw lists, and for a broad overview. However, it doesn't explicitly state when NOT to use it or name alternatives for detailed trade-level queries, relying on the sibling names as context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A whole-market gauge rather than a per-company one. 'macro' is the market-regime read, 'energy' the macro energy balance, 'crypto' crypto positioning and funding, 'rate_expectations' the market-implied path for policy rates. Use these for the backdrop a single name is trading against.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds meaningful scope context ('whole-market' vs per-company) and semantics for each enum option, but does not disclose output format or behavior beyond the annotation.
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 no wasted words. The market-level scope is front-loaded, followed by a compact definition of every enum option and a practical usage note. 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?
For a single-parameter enum tool with a read-only annotation, the description covers scope, all parameter values, and when to use it. It does not describe the return shape, but the absence of an output schema makes that a minor gap for a tool this simple.
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 0%, so the description carries the burden of explaining the 'name' parameter. It successfully defines all four enum values ('macro', 'energy', 'crypto', 'rate_expectations') with concrete meanings, going well beyond their bare labels.
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 identifies a specific resource ('whole-market gauge') and distinguishes it from per-company tools. It enumerates the four distinct signals, but it never explicitly states a verb like 'retrieves' or 'returns', relying on 'gauge' and tool name to imply the action.
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 a clear use case: 'Use these for the backdrop a single name is trading against.' This tells the agent when the tool is appropriate, though it does not name sibling alternatives or state explicit exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disclosed House and Senate trades, newest first, linked to the disclosure where one is available. Up to 20 rows per call on every customer key; page with next_cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many trades to return. | |
| since | No | ISO date; only records on or after it. | |
| cursor | No | next_cursor from a previous call. | |
| ticker | No | Restrict to one ticker, e.g. TSLA. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint already covers the safety profile, yet the description adds genuinely useful behavior: a hard 20-row cap per call on every customer key, newest-first ordering, and cursor-based pagination. It does not describe what a row contains, but for an annotated read tool this is solid extra context.
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, zero filler, with the resource scope front-loaded and pagination behavior immediately after. Every clause carries information.
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, the description covers ordering, row cap, disclosure linkage and pagination, which is most of what an agent needs. It stops short of describing the row fields (ticker, politician, date, size), a minor gap for a read-only list 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 baseline is 3, but the description adds meaning the schema lacks: the 20-row ceiling effectively caps the limit parameter regardless of key, and it explains that cursor comes from a prior call's next_cursor. That goes beyond the one-line schema descriptions.
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?
Specific verb+resource: it lists disclosed House and Senate trades, states the ordering (newest first) and the disclosure linkage. An agent can distinguish it from the sibling list_insider_trades without opening either 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?
It gives concrete operating guidance (up to 20 rows per call, page with next_cursor) but never states when to choose this tool over list_insider_trades or the other list_* siblings, and imposes no exclusions. Usage is implied by the resource name rather than explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Funding rate and open interest for the ~51 US single names listed on a 24/7 perpetual futures venue, ranked by notional. This is the ONLY source here that moves outside US market hours, so it is what to check overnight and at weekends. High positive funding means longs are paying to hold — crowded, squeeze-fragile. The mark price is a venue mark, NOT the stock price.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many names to return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds critical behavioral context: the mark price is a venue mark, not the stock price, and high positive funding indicates crowded, squeeze-fragile positioning. This is valuable non-obvious information that significantly enhances understanding.
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 dense, purposeful sentences. The first defines the tool, the second specifies when to use it, and the third explains how to interpret the data. Zero fluff or redundancy.
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 tool with one parameter, high schema coverage, and a readOnly annotation, the description is remarkably complete. It covers purpose, usage timing, interpretation, and a critical caveat about the mark price. No output schema is needed to understand the returned data.
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 already describes the 'limit' parameter (100% coverage), so baseline is 3. The description adds meaning by revealing the universe size (~51 names) and that results are ranked by notional, which informs how limit should be interpreted and used.
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 lists funding rate and open interest for ~51 US single-name perpetuals, ranked by notional. This specific verb+resource+scope distinguishes it from sibling tools like get_equity_perp, and the added 'ONLY source here that moves outside US market hours' context further differentiates its purpose.
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 explicitly states when to use it ('what to check overnight and at weekends') and even explains it is the 'ONLY source' for that use case. It does not explicitly name alternatives or state when not to use it, but the guidance is clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Corporate insider buys and sells from SEC filings, newest first, with a link to the filing each came from where one is available.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many trades to return. | |
| since | No | ISO date; only records on or after it. | |
| cursor | No | next_cursor from a previous call. | |
| ticker | No | Restrict to one ticker, e.g. TSLA. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read. The description adds real behavioral context on top: results are ordered newest first and each row links to the source filing when available. It does not mention pagination via cursor, auth requirements, or rate limits.
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 efficient sentence with no filler, and the key information (source, ordering) is front-loaded. Slightly dense but nothing is wasted.
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 read-only list tool with full schema coverage and no output schema, the description conveys source, ordering, and the filing link. Filtering behavior (ticker/since/cursor) is covered by the schema, so nothing essential 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%, so limit, since, cursor, and ticker are all documented in the schema. The description adds no parameter-level detail beyond that, 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: corporate insider buys and sells from SEC filings. An agent can tell this is insider-trade data, but the description never distinguishes it from the nearby sibling list_congress_trades or any other listing tool.
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?
No when-to-use guidance, no prerequisites, and no alternatives named. The implied context (recent insider activity) is left entirely to inference, and with a sibling like list_congress_trades present the omission is meaningful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Weekly speculative positioning in FUTURES markets from the CFTC Commitments of Traders report, newest first: net speculative position, its share of open interest and its historical percentile. Covers futures symbols such as ES (S&P 500 e-mini), GC (gold), ZT (2-year Treasury note), not individual stocks. Net figures can reflect hedges and cannot be read as a directional view on their own.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many records to return. | |
| since | No | ISO date; only records on or after it. | |
| cursor | No | next_cursor from a previous call. | |
| ticker | No | Futures symbol as the CFTC data stores it, e.g. ES, GC, ZT. Not an equity ticker. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true. The description goes beyond that by disclosing the ordering ('newest first'), the upstream source, and an interpretive caveat that net figures can include hedges. It does not discuss pagination or rate limits, but the added semantic context is substantial for a read-only list 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?
Two sentences that front-load the data source and returned fields, then append the caveat. Efficient, though the enum of example symbols (ES, GC, ZT) is somewhat redundant with the schema and could be trimmed.
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, the description usefully names the return values (net speculative position, share of open interest, historical percentile) and notes ordering. Combined with full schema coverage, an agent has what it needs; only the hedging caveat's practical implication for interpretation is left loose.
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 limit, since, cursor and ticker are already documented in the schema, and the description's ticker note ('Not an equity ticker') largely duplicates the schema text. Baseline 3 applies since the schema does the heavy lifting and the description adds no new parameter semantics.
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 ('Weekly speculative positioning in FUTURES markets from the CFTC Commitments of Traders report') and enumerates the exact return fields, which sharply separates it from the equity-centric siblings (list_insider_trades, list_congress_trades). An agent can identify the domain without opening the 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?
It clearly scopes usage ('Covers futures symbols such as ES, GC, ZT, not individual stocks') and warns that net figures 'cannot be read as a directional view on their own.' That is strong context, but it never names a competing tool or an explicit when-to-use condition, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The names where independent actors agree most strongly, ranked. Use this to find candidates rather than to check one you already have in mind.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many rows to return. | |
| direction | No | Restrict to one consensus direction. | |
| min_signals | No | Minimum number of dimensions that voted. | |
| min_agreement | No | Minimum agreement score, 0-1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds context about 'independent actors agree most strongly' (the ranking logic), but doesn't mention operational details like default ordering, pagination, or what happens when filters are omitted. 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 concise, front-loaded sentences: the first states what the tool does, the second gives usage guidance. No redundant words or repetition of schema details.
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 read-only ranking tool with 4 optional, well-described parameters and no output schema, the description gives enough purpose and usage context. It could mention how filters interact with ranking, but the presence of schema descriptions and the readOnly annotation keeps it complete enough for selection.
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% – every parameter has a description (limit, direction, min_signals, min_agreement). The tool description adds no additional parameter meaning beyond the schema, so the baseline of 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 clearly states it returns 'names where independent actors agree most strongly, ranked' – a specific verb+resource (ranked list of consensus names). It distinguishes from siblings by contrasting with 'to check one you already have in mind', making its screening purpose explicit.
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 explicitly says 'Use this to find candidates rather than to check one you already have in mind' – giving clear when-to-use direction and an implicit when-not-to-use. It doesn't name alternative tools, but the contrast is strong enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Filter the whole equity universe and return matching tickers with their scores. The bulk discovery tool: use it for questions of the form 'which companies have X'. To rank by cross-signal agreement instead, use rank_consensus.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort column. Defaults to confidence. house_rating_confidence requires a paid key. | |
| limit | No | How many rows to return. | |
| order | No | Sort direction. | |
| state | No | Restrict to one overall state. | |
| rating | No | Restrict to one house rating, e.g. buy, hold, sell. Requires a paid key. | |
| sector | No | Restrict to one sector. | |
| flagged | No | Only entities with at least one event or risk dimension flagged (insider, material, macro, ftd, reporting_risk, ownership, news, ta, institutional, congress, fda_enforcement). Flags on fundamentals, macro_beta, narrative and gov_contracts do not count. | |
| min_confidence | No | Minimum model confidence, 0-1. | |
| min_completeness | No | Minimum data completeness, 0-1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read, so the description's added value is limited to characterizing the operation as a broad universe scan rather than a targeted lookup. It does not mention default sort/limit behavior, result volume, or the paid-key gating visible only in the schema, so it adds some but not rich behavioral context.
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 tightly written sentences, front-loaded with the core action and immediately followed by the routing rule. Every clause earns its place with no padding.
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 9-parameter, 0-required filter tool with full schema coverage and no output schema, the description covers what it does and when to prefer a sibling. It is slightly thin on return-shape expectations (row volume, ticker+score payload) but nothing essential for correct invocation 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%, including enum meanings and the paid-key caveats on house_rating_confidence and rating, so the baseline is 3. The description contributes no parameter-level detail (e.g., limit semantics or interaction between sort/order) beyond what the schema already 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?
States a specific verb+resource+scope: 'Filter the whole equity universe and return matching tickers with their scores.' It also names the sibling it is not (rank_consensus for cross-signal ranking), so an agent can distinguish it from the get_* and list_* siblings without opening schemas.
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 labels itself 'the bulk discovery tool' and gives the triggering question shape ('which companies have X'), plus a concrete alternative and the condition that selects it ('To rank by cross-signal agreement instead, use rank_consensus'). This is exactly when/when-not/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a company name or partial symbol to tickers the platform covers. Use this first when the user names a company rather than a symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Company name or partial symbol. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds the scoping constraint ('the platform covers'), which is useful, but does not mention output format, pagination, or edge cases. It meets the baseline but does not go beyond.
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 purpose, and no wasted words. Every sentence contributes value, and the structure is ideal for quick parsing by an AI agent.
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, read-only lookup tool with no output schema, the description provides enough context: what it does, its scope, and when to use it. No critical information 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%, so the schema already fully documents the 'query' parameter. The description restates the same meaning without adding new semantic detail, so the baseline of 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 has a specific verb ('resolve'), a clear resource ('tickers'), and a defined scope ('the platform covers'). It clearly distinguishes itself from sibling tools by being the only search/resolution tool in the list.
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 when to use this tool: 'Use this first when the user names a company rather than a symbol.' This provides clear context for tool selection, even though alternatives are not named.
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.
screen1 field changedInput schema / properties / state / enumPrevious value: -[
- "accumulation",
- "distribution",
- "event_driven",
- "elevated_risk",
- "mixed",
- "quiet"
-]New value: +[
+ "accumulation",
+ "distribution",
+ "event_driven",
+ "elevated_risk",
+ "mixed",
+ "quiet",
+ "activist_target",
+ "settlement_stress"
+]screen1 field changedInput schema / properties / flagged / descriptionPrevious value: -"Only entities carrying at least one risk flag."New value: +"Only entities with at least one event or risk dimension flagged (insider, material, macro, ftd, reporting_risk, ownership, news, ta, institutional, congress, fda_enforcement). Flags on fundamentals, macro_beta, narrative and gov_contracts do not count."list_positioning1 field changedInput schema / properties / ticker / descriptionPrevious value: -"Restrict to one ticker, e.g. TSLA."New value: +"Futures symbol as the CFTC data stores it, e.g. ES, GC, ZT. Not an equity ticker."screen1 field changedInput schema / properties / state / enumAdded value: +[
+ "accumulation",
+ "distribution",
+ "event_driven",
+ "elevated_risk",
+ "mixed",
+ "quiet"
+]get_signal1 field changedInput schema / properties / name / enumPrevious value: -[
- "macro",
- "energy",
- "crypto"
-]New value: +[
+ "macro",
+ "energy",
+ "crypto",
+ "rate_expectations"
+]get_monthly_activityscreen2 fields changedInput schema / properties / rating / descriptionPrevious value: -"Restrict to one house rating, e.g. buy, hold, sell."New value: +"Restrict to one house rating, e.g. buy, hold, sell. Requires a paid key."Input schema / properties / sort / descriptionPrevious value: -"Sort column. Defaults to confidence."New value: +"Sort column. Defaults to confidence. house_rating_confidence requires a paid key."get_compositeget_consensusget_demo_compositeget_equity_perpget_evidenceget_historic_movesget_house_ratingget_signallist_congress_tradeslist_equity_perplist_insider_tradeslist_positioningrank_consensusscreensearch_tickersInsider, Congress, 13F and federal contract filings for US stocks, each linked to its source.
Financial intelligence: insider trades, SEC filings, 13F holdings, and market signals.
Explainable model signals, drivers, news sentiment, SEC filings and macro data for US stocks.
US stock and ETF research: Congress and insider trades, earnings, picks vs SPY. Sign-in required.
Add one secure layer between your agents and this server.
