HoldingsIntel

by com.holdingsintel

Find Signals

find_signals

Read-only

Screens for stocks or fund moves matching a signal type. Use this when the user wants a list, not a single stock.

WHEN TO USE: User asks for a screen, list, or "what's interesting right now". Types:

convergence: stocks with institutional coverage where 2+ available filing-source signals align
conviction: highest-conviction recent moves
double_downs: positions increased while price fell
new_positions: fresh entries this quarter
smart_money_buying: stocks with strictly positive conviction-weighted institutional sentiment
early_birds: first-mover funds discovering new positions

Examples:

"Show me stocks where smart money is converging"
"What are the highest conviction buys this quarter?"
"Which funds are doubling down into price weakness?"

WHEN NOT TO USE:

Use analyze_stock when the user names a specific stock

PARAMETERS: sector applies only to convergence; quarter is unavailable for convergence and otherwise defaults to the newest default-ready 13F quarter; min_score is unavailable for early_birds. smart_money_buying always requires conviction_weighted_sentiment > 0, even when min_score is omitted or zero. Unsupported combinations are rejected, never ignored.

RETURNS: A cursor-paginated ranked list with the relevant score and source metrics, a filing period for quarter-bound types, and an exact total when the underlying dataset supports one. Convergence is a mixed-source snapshot; because its backing view exposes no exact common data-through date, provenance returns null and data_status states that limitation.

VERIFICATION: Cite record-level source_url filing or disclosure links when present.

Input Schema

TableJSON Schema

Name	Required	Description
`type`	Yes	Signal taxonomy; convergence includes only aligned 2+ source composites with institutional coverage, and smart_money_buying requires conviction_weighted_sentiment > 0.
`limit`	No
`cursor`	No
`sector`	No
`quarter`	No
`min_score`	No

Output Schema

TableJSON Schema

Name	Required	Description
`page`	Yes
`type`	Yes	Signal taxonomy; convergence includes only aligned 2+ source composites with institutional coverage, and smart_money_buying requires conviction_weighted_sentiment > 0.
`access`	No
`results`	Yes
`provenance`	No
`data_status`	No

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds substantial behavior beyond those: unsupported combinations are rejected rather than ignored, convergence provenance returns null with data_status explaining the limitation, and output is a cursor-paginated ranked list. No contradiction exists between description and annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer due to complex signal taxonomy, but every section earns its place: scoping, enumerated types, examples, exclusions, parameter quirks, return semantics, and verification guidance. It is front-loaded with the key purpose, then organized into scannable labeled blocks.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema and annotations already covering read-only behavior; the description fills the remaining gaps by clarifying the six signal types, parameter compatibility constraints, default quarter behavior, ranking/pagination nature, and provenance limitations. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 17%, and the description compensates well by explaining type-specific constraints, quarter defaults, smart_money_buying's inherent requirement, and min_score restrictions for early_birds. It does not fully describe cursor semantics, but the 'cursor-paginated' return statement covers the essential behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Screens for stocks or fund moves matching a signal type.' It immediately differentiates from analyze_stock by stating this is for lists, not single stocks, and enumerates six distinct signal types with concrete meanings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The tool includes a dedicated 'WHEN TO USE' section with concrete triggers ('asks for a screen, list, or what's interesting right now') and a 'WHEN NOT TO USE' section pointing to analyze_stock as the alternative for named stocks. Example queries further reinforce when an agent should select this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All HoldingsIntel tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0

Disambiguation5/5

Every tool has a clearly distinct purpose, reinforced by explicit 'WHEN TO USE' and 'WHEN NOT TO USE' guidance. Overlapping concepts like get_13f_activity vs get_stock_holders vs get_fund_holdings are precisely scoped to changes, holders, or full portfolios, leaving no ambiguity for an agent.

Naming Consistency4/5

Names largely follow a verb_noun pattern with consistent snake_case, but there is minor variation in CRUD verbs: add_saved_list_item vs create_saved_list, delete_saved_list vs remove_saved_list_item, and update_saved_list_item_notes. These are understandable but not perfectly uniform; otherwise naming is predictable.

Tool Count4/5

At 24 tools, the server is on the heavy side of the ideal range, but the breadth of the domain (stocks, funds, politicians, insider trades, activist stakes, screenings, saved lists, status) justifies each tool. It feels comprehensive without being bloated, though it could benefit from consolidation in a few areas.

Completeness5/5

The tool surface covers the full lifecycle of the domain: security lookups, stock analysis, fund profiling and comparison, backtesting, politician trading, insider and activist feeds, screenings, quarter metadata, and saved-list management. There are no obvious gaps or dead ends; the set feels complete for the stated purpose.

Resources

Need Help?