Wealthnow

SEC 13F Holdings

intel_sec13f

Read-onlyIdempotent

13F position snapshots from the institutional 13F archive: fund, ticker, shares, value_usd, report_period (the institutional-ownership signal). Call this when the user asks 'which funds hold X?' or 'what does fund Y own?'; filter by ticker and/or fund (substring match). The archive ends a quarter behind EDGAR: answers carry newest_report_period, vendor_ceiling, expected_report_period, is_stale and quarters_behind. A ticker is read on its share class's CUSIP (security_key; GOOGL and GOOG are separate). missing_known_filers and coverage_note name manager families whose 13F filings the archive does not carry for the quarter (Vanguard's successor filers from 2026-03-31), so their positions are absent, not sold. fund is the archive's manager label; fund_current_name gives today's name where the label is a former one (manager_name_note). For a ticker, current_quarter adds the newer EDGAR 13F filings of the tracked managers only (coverage 'tracked_managers_only', report_period on each item); it is not the full holder list. current_quarter_error says those filings could not be read. Alternative-data rows served because the archive could not be read carry archive_error; fallback rows are the filings it has indexed, not a full holder list (coverage_note). When neither source can answer the route returns 503 upstream_unavailable (error_code archive_read_timeout, archive_read_failed or upstream_dead_no_archive; not billed), never an empty list.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "intel_sec13f"
  }
}

Input Schema

Name	Required	Description
`fund`	No	Substring match on fund name. Length: at most 80 characters.
`limit`	No	Allowed: 1 to 500.
`ticker`	No	Only positions in this ticker, for example AAPL; use it with fund or alone. Length: at most 12 characters.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With annotations already covering the read-only/idempotent safety profile, the description adds substantial non-structured context: archive lag behind EDGAR (newest_report_period, vendor_ceiling, quarters_behind), firm-level coverage gaps (missing_known_filers, Vanguard successor filers), CUSIP share-class separation of GOOGL/GOOG, and precise failure behavior (503 upstream_unavailable, three error codes, not billed). This is exactly the behavioral detail an agent cannot get from annotations.

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

Conciseness4/5

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

Purpose and invocation trigger are front-loaded, and no sentence is filler given there is no output schema to document return fields. However, it is an unusually dense single block covering fields, staleness, coverage gaps, fallbacks and error codes, which makes it harder to scan than it needs to be.

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?

For a zero-required-parameter, no-output-schema, open-world tool with a lagged upstream archive, the description supplies everything needed: response field meanings, staleness indicators, coverage caveats, fallback semantics, and terminal error codes. An agent could call and interpret this correctly without further context.

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 coverage is 100%, so baseline is 3, but the description clarifies that fund matches the archive's manager label (with fund_current_name for renamed labels) and that ticker keys off the share class's CUSIP rather than a company. That CUSIP/share-class caveat materially changes how ticker should be supplied and goes beyond the schema line.

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?

Opens with a specific verb+resource ('13F position snapshots from the institutional 13F archive') and enumerates the returned fields (fund, ticker, shares, value_usd, report_period). The example questions ('which funds hold X?', 'what does fund Y own?') make the tool's function unmistakable and separate it from generic filings/insider siblings.

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

Usage Guidelines4/5

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

Gives explicit invocation triggers via the two example user questions, plus filtering guidance ('filter by ticker and/or fund') and a scope exclusion for current_quarter ('it is not the full holder list'). No sibling tool is named as an alternative, so routing to the wrong 13F-like tool is still possible, but the usage conditions themselves are clear.

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

All Wealthnow tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.