Skip to main content
Glama

Search stocks, institutions, insiders and politicians

search
Read-onlyIdempotent

Find US stocks, 13F institutions (including the curated superinvestors, matched by fund or manager name, e.g. 'Buffett' or 'Pershing', and large asset managers matched by their common name, e.g. 'Fidelity' finds FMR LLC and 'Capital Group' its three 13F filers), corporate insiders (Form 4 reporting persons) and politicians (members of the U.S. Congress: House and Senate members who served in 2019 or later, by name, nickname, last name or bioguide ID; current members first) by ticker or name. Returns up to limit matches per group, best match first, with the identifier the other tools take: ticker for get_stock, get_insider_trades, get_stock_13f_holders, get_major_holders and the other stock filters; institution cik for get_institution and get_ownership_filings(filer_cik); insider cik for get_insider_trades(insider_cik) and get_form144_notices(seller_cik); politician bioguide for get_politician and get_politician_trades(politician). Names are SEC names in English (insiders appear as 'Cook Timothy D'); superinvestors and those asset managers also match their Chinese names. Tickers match exactly or by prefix; a CIK (e.g. 1067983) or a 9-character CUSIP (e.g. 037833100) matches exactly; names need at least 2 characters. Stocks carry the company in name; detail is the manager for superinvestors ('13F filer' for other institutions) and the latest title and company for insiders. Politicians have party (D, R, I), chamber (house or senate), state, district (House seats; 0 is at-large) and in_office. Every item has its livermore.club url.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum matches per group (1-20, default 5).
queryYesTicker, company, fund, manager, person or politician name, CIK or CUSIP.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes
stocksYes
insidersYes
politiciansYes
institutionsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / query / description
      Previous value: -"Ticker, company, fund, manager, person or member of Congress name, CIK or CUSIP."New value: +"Ticker, company, fund, manager, person or politician name, CIK or CUSIP."
    • removedOutput schema / properties / members
      Removed value: -{
      -  "items": {
      -    "additionalProperties": false,
      -    "properties": {
      -      "bioguide": {
      -        "type": "string"
      -      },
      -      "chamber": {
      -        "enum": [
      -          "house",
      -          "senate"
      -        ],
      -        "type": "string"
      -      },
      -      "district": {
      -        "type": [
      -          "number",
      -          "null"
      -        ]
      -      },
      -      "in_office": {
      -        "type": "boolean"
      -      },
      -      "name": {
      -        "type": "string"
      -      },
      -      "party": {
      -        "type": [
      -          "string",
      -          "null"
      -        ]
      -      },
      -      "state": {
      -        "type": "string"
      -      },
      -      "url": {
      -        "type": "string"
      -      }
      -    },
      -    "required": [
      -      "bioguide",
      -      "name",
      -      "party",
      -      "chamber",
      -      "state",
      -      "district",
      -      "in_office",
      -      "url"
      -    ],
      -    "type": "object"
      -  },
      -  "type": "array"
      -}
    • addedOutput schema / properties / politicians
      Added value: +{
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "bioguide": {
      +        "type": "string"
      +      },
      +      "chamber": {
      +        "enum": [
      +          "house",
      +          "senate"
      +        ],
      +        "type": "string"
      +      },
      +      "district": {
      +        "type": [
      +          "number",
      +          "null"
      +        ]
      +      },
      +      "in_office": {
      +        "type": "boolean"
      +      },
      +      "name": {
      +        "type": "string"
      +      },
      +      "party": {
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      },
      +      "state": {
      +        "type": "string"
      +      },
      +      "url": {
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "bioguide",
      +      "name",
      +      "party",
      +      "chamber",
      +      "state",
      +      "district",
      +      "in_office",
      +      "url"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "query",
      -  "stocks",
      -  "institutions",
      -  "insiders",
      -  "members"
      -]New value: +[
      +  "query",
      +  "stocks",
      +  "institutions",
      +  "insiders",
      +  "politicians"
      +]
  2. Changed3 schema fields changed
    • changedInput schema / properties / query / description
      Previous value: -"Ticker, company, fund, manager or person name."New value: +"Ticker, company, fund, manager, person or member of Congress name, CIK or CUSIP."
    • addedOutput schema / properties / members
      Added value: +{
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "bioguide": {
      +        "type": "string"
      +      },
      +      "chamber": {
      +        "enum": [
      +          "house",
      +          "senate"
      +        ],
      +        "type": "string"
      +      },
      +      "district": {
      +        "type": [
      +          "number",
      +          "null"
      +        ]
      +      },
      +      "in_office": {
      +        "type": "boolean"
      +      },
      +      "name": {
      +        "type": "string"
      +      },
      +      "party": {
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      },
      +      "state": {
      +        "type": "string"
      +      },
      +      "url": {
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "bioguide",
      +      "name",
      +      "party",
      +      "chamber",
      +      "state",
      +      "district",
      +      "in_office",
      +      "url"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "query",
      -  "stocks",
      -  "institutions",
      -  "insiders"
      -]New value: +[
      +  "query",
      +  "stocks",
      +  "institutions",
      +  "insiders",
      +  "members"
      +]
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds substantial behavior beyond that: per-group result cap, best-match-first ordering, politicians sorted current-members-first, matching semantics (exact/prefix ticker, exact CIK/CUSIP, 2-char minimum for names), and the meaning of the `detail` field per group.

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 is front-loaded in the opening clause and every subsequent sentence carries non-redundant information. It is dense and somewhat run-on with nested parentheticals, which slightly taxes readability, but there is little wasted text.

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?

Given an output schema exists, the description appropriately focuses on input interpretation and cross-tool routing while still noting the per-item `detail` and `url` fields. For a resolver feeding eight-plus siblings, this is complete enough for an agent to call it correctly and consume its output.

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 the baseline is 3, but the description adds real meaning: it interprets `query` by spelling out how tickers, CIKs, CUSIPs and names are matched, and clarifies that names are SEC English names with Chinese-name matching for superinvestors/asset managers. `limit` is explained as a per-group cap, adding nuance beyond the schema's 'maximum matches per group'.

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?

States a specific verb (find) and enumerates the exact resources searched (US stocks, 13F institutions/superinvestors, corporate insiders, politicians) with the disambiguating detail that it searches by ticker or name. It goes further by naming which sibling each returned identifier feeds (ticker→get_stock, institution cik→get_institution, etc.), so an agent can instantly tell it apart from the retrieval 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?

The description makes its role clear as a resolver that yields the identifiers the other tools consume, giving strong context for when to reach for it first. It names the downstream siblings explicitly, but it does not state any exclusion or 'when not to use' condition (e.g. when to skip search and call a sibling directly).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources