Clean SEC EDGAR company financials for AI agents — normalized income statement, balance sheet, cash flow, computed ratios, company profiles, filings, and 10-K/10-Q narrative sections (Risk Factors, MD&A) for 10,000+ US public companies. 5 tools: get_fundamentals, get_ratios, get_company, get_filings, get_sections. Free tier, no card.
Schedule 13D/13G filings, the disclosure anyone crossing 5% of a company's voting stock must make. A 13D signals possible activist intent; a 13G is a passive large holder. Each record has the issuer, CUSIP, reporting person(s), and exact percent of class. Pass identifier='latest' for the market-wide feed of new >5% stakes, or a ticker for the stakes indexed on that company.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of filings, 1-100 (default 40). | |
| identifier | Yes | 'latest' for the market-wide >5% feed, or a US ticker (e.g. 'AAPL') for stakes indexed on that company. | |
| min_percent | No | For 'latest': minimum percent of class (default 0). | |
| activist_only | No | For 'latest': keep only 13D (activist-intent) filings (default false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, idempotent, and non-destructive behavior, so the description does not need to repeat those. It adds value by explaining the meaning of the filings (13D vs 13G) and the exact fields returned (issuer, CUSIP, reporting person(s), percent of class). This contextual disclosure goes beyond annotations and helps the agent understand the tool's output semantics without an 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?
The description is four sentences long but each sentence earns its place: it defines 13D/13G, clarifies the threshold, lists the record fields, and explains the identifier modes. It is front-loaded with purpose and avoids filler, though the first two sentences could arguably be condensed. Overall it is efficient and well-structured for an agent scanning for key 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?
Given no output schema, the description provides a useful outline of return fields (issuer, CUSIP, reporting person(s), percent). It also covers the two invocation modes thoroughly. It does not mention pagination, error behavior, or edge cases, but for a read-only, idempotent tool with a single required parameter, these are less critical. The description is sufficient for correct invocation and basic outcome expectations.
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?
All four parameters are fully described in the schema (100% coverage), so the baseline is 3. The description adds meaningful depth to the required 'identifier' parameter by explaining the two distinct value modes ('latest' vs ticker) and their purposes, which the schema merely hints at. This elevates the semantic clarity of the most important parameter beyond what the schema alone 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?
The description names a specific resource (13D/13G activist stakes) and a clear action (get/fetch), going beyond the name to explain the domain context (5% threshold, 13D vs 13G). It also distinguishes two modes of operation (latest vs ticker) that align with the identifier parameter, making the purpose unambiguous and distinguishable from sibling tools like get_holdings or get_filings.
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 tells the agent when to use each identifier value: 'Pass identifier='latest' for the market-wide feed... or a ticker for the stakes indexed on that company.' This is clear usage guidance for the primary parameter. It does not explicitly compare against alternatives (e.g., get_holdings), but the distinction between activist stakes and general holdings is implicit. The guidance is specific enough to correctly invoke the tool for both intended scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CIK, legal name, SIC industry, fiscal-year end, exchanges and website for a ticker, resolved from SEC EDGAR submissions.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | US stock ticker, e.g. 'AAPL'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe, read-only, idempotent behavior. The description adds transparency about the data source (SEC EDGAR submissions) and the specific fields returned, providing context beyond the annotations. No contradictions found.
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 sentence that efficiently lists the returned fields and the data source. No unnecessary words or repetition.
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 single parameter, high annotation coverage, and no output schema, the description is nearly complete. It specifies the output fields and source. Minor omission: it does not explicitly state that the tool returns a single company, but this is implied by the ticker parameter.
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 has 100% coverage with a clear description for 'ticker'. The description does not add additional meaning beyond the schema's definition, so a 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 returns specific company profile fields (CIK, legal name, SIC industry, etc.) for a given ticker, resolved from SEC EDGAR. It distinguishes from sibling tools like get_filings or get_fundamentals by specifying the exact output type.
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 retrieving a company profile but lacks explicit when-to-use or when-not-to-use guidance. It does not mention alternatives or conditions, though sibling names provide some context. Usage is implied rather than directly instructed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
8-K material events for a ticker as typed items (2.02 earnings, 5.02 executive change, 1.05 cybersecurity incident, 2.01 acquisition, etc.), each with a notable flag for the market-moving ones and a link to the filing. Pass item to filter to one event type (e.g. '4.02' for every restatement a company filed). Pass ticker='restatements' or 'auditor-changes' for the market-wide red-flag feed of recent item 4.02 / 4.01 8-Ks across all filers.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | For the market-wide feeds: lookback window in days (default 45). | |
| item | No | Filter to a specific 8-K item code, or comma-separated codes, e.g. '4.02' (restatement) or '5.02,2.02'. | |
| limit | No | Number of events, 1-100 (default 20; 50 for feeds). | |
| ticker | Yes | US stock ticker (e.g. 'AAPL'), or 'restatements' / 'auditor-changes' for the market-wide item feed. | |
| notable | No | Only market-moving events (default false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent, so no safety disclosure is needed; the description adds behavior beyond annotations: returned events are typed items, have a notable flag for market-moving events, include a filing link, and support a market-wide red-flag feed for items 4.02/4.01. It does not contradict 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?
Three sentences, all substantive: purpose and output elements are front-loaded, then filtering and special feeds. There is no filler or repetition of schema 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 moderate-complexity read-only tool with fully described parameters and safety annotations, the description covers the main output elements and the two special modes. An agent can select and call it correctly without additional information.
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 covers all five parameters with descriptions (100% coverage), so baseline is 3. The description adds meaning beyond the schema by mapping item codes to real-world event types (2.02 earnings, 4.02 restatement), explaining the notable-flag concept, and clarifying the special ticker feed behavior.
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 ('Get') and resource ('8-K material events') with defining details: typed items, notable flag, filing link, and special market-wide feeds. This clearly distinguishes it from sibling tools like get_filings or search_filings by scoping to 8-K event type items.
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 explicit usage context for filtering by item code and for the special ticker values 'restatements'/'auditor-changes', which is more than implied usage. It does not explicitly name alternatives or when-not-to-use, but the main use case and special modes are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent SEC filings for a ticker (10-K/10-Q/8-K) with filing/report dates and document links.
| Name | Required | Description | Default |
|---|---|---|---|
| form | No | Optional form filter, e.g. '10-K', '10-Q', '8-K'. | |
| limit | No | Number of filings to return, 1-100 (default 20). | |
| ticker | Yes | US stock ticker, e.g. 'AAPL'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and open world behavior. The description adds that the output includes filing/report dates and document links, but does not detail other behaviors (e.g., pagination, rate limiting). It adds some value beyond 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?
The description is a single, front-loaded sentence with no redundant words. Every part contributes to understanding the tool's core function.
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 three parameters and no output schema, the description provides adequate context about the response content. However, it lacks details on the recency or ordering of filings (e.g., defaults to last 20).
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%, providing clear parameter definitions. The tool description adds no additional parameter information, so it meets the baseline expectation.
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 retrieves recent SEC filings for a ticker, mentioning common form types and response contents (dates and links). It distinguishes the tool's purpose but does not explicitly differentiate from sibling tools.
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 guidance is provided on when to use this tool versus alternatives (e.g., get_fundamentals, get_insider). The description lacks when/when-not and alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parsed Form D notices — the filing a company makes when it raises money in a private placement under a Regulation D exemption. Each carries the issuer, jurisdiction, industry, amount offered and sold, the exemption, related persons, and date of first sale. Pass a CIK (or ticker if public) for one issuer, or 'latest' for the market-wide feed of new private raises.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of notices, 1-100 (default 20 for latest, 10 per issuer). | |
| identifier | Yes | Issuer CIK (Form D issuers are usually private), a ticker if public, or 'latest' for the market-wide feed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive, so the description doesn't need to restate that. It adds value by clarifying the output content (issuer, jurisdiction, industry, amounts, exemption, related persons, date of first sale), which helps the agent understand what the parsed result will look like. No contradictory behavior is mentioned.
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 sentences long, front-loading the definition and then giving clear usage instructions. Every word adds value, and it effectively communicates the tool's purpose and input paradigm without unnecessary detail or 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 simple read-only tool with only two parameters, the description provides sufficient context: what data is returned, how to specify an issuer vs. the latest feed, and the general nature of the filings. The lack of a detailed output schema is compensated by listing the mapped fields in the description. Minor gaps like pagination or error handling are not critical given the tool's simplicity and the annotation-provided safety profile.
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 already covers both parameters (identifier, limit) with detailed descriptions. The tool description repeats the identifier usage (CIK/ticker/latest) but adds no new semantic information beyond the schema. Given the 100% schema coverage, a baseline score of 3 is appropriate; the description doesn't further clarify parameter behavior or defaults beyond what's already documented.
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 defines what the tool does: it provides parsed Form D notices, a specific type of SEC filing for private placements. It distinguishes itself from sibling tools by focusing on a niche filing type and enumerating the data fields returned, making it unmistakable which resource is accessed.
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 explicit usage instructions: pass a CIK (or ticker if public) for a single issuer, or use 'latest' for the market-wide feed. This tells the agent how to invoke the tool with different identifier types, but it does not explicitly contrast with alternatives like get_filings or search_filings, though the unique focus on Form D makes the intended use fairly evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Normalized income statement, balance sheet, and cash flow for a US-listed ticker, parsed from SEC EDGAR XBRL. Counts as one request on the Edgrapi plan.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of periods to return, 1-20 (default 5). | |
| period | No | Reporting period (default annual). | |
| ticker | Yes | US stock ticker, e.g. 'AAPL'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds context about the data source (SEC EDGAR XBRL) and billing plan, which are beneficial beyond the annotations. No contradictions.
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: first defines purpose and source, second adds billing info. No redundant phrases, perfectly front-loaded and efficient.
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 simplicity (3 parameters, no output schema), the description is complete: it specifies the financial statements returned, data source, and billing cost. Could mention normalization briefly, but not necessary.
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 schema already documents all parameters. The description adds no additional semantic meaning for the parameters beyond what's in the schema, which is adequate but not enhanced.
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 retrieves 'income statement, balance sheet, and cash flow' for a US-listed ticker from SEC EDGAR XBRL. This distinguishes it from siblings like get_ratios or get_filings.
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 mentions the billing impact ('counts as one request'), but does not explicitly state when to use this tool versus alternatives like get_ratios or get_filings. Usage is implied by name and purpose but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A fund's latest 13F portfolio parsed from the SEC information table: every position ranked by value, aggregated by CUSIP across sub-managers, options flagged put/call, and diffed against the prior quarter (new / added / reduced / exited). Identify the fund by a known name (berkshire, burry, ackman, bridgewater, citadel), a CIK, or a filer ticker (BRK-B).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max positions, 1-500 (default 50). | |
| changes | No | Diff vs the prior quarter (default true). | |
| identifier | Yes | Fund name (e.g. 'berkshire', 'burry', 'pershing-square'), a CIK, or a ticker whose company files the 13F (e.g. BRK-B). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral context beyond annotations: it notes data is parsed from the SEC info table, aggregated by CUSIP across sub-managers, options flagged, and diffed against prior quarter. However, it doesn't disclose edge cases like unknown identifiers or handling of missing prior quarter data, nor does it describe the return format. For a read-only tool with strong annotations, a 3 is appropriate.
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 sentences with no redundancy. The main output is front-loaded, followed by identifier guidance. Every clause adds information: what is parsed, how it's aggregated, how options and diffs are handled, and how to find a fund. Efficient and well-structured.
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 annotations already cover safety and idempotency, and the schema documents all three parameters with examples, the description is complete for a read-only query tool. It explains the data source, aggregation, and diffing logic, which are core behaviors. It lacks explicit return-type documentation, but the output schema is absent and the description's detail suggests the agent will get ranked positions. Minor gap: no mention of pagination beyond 'limit', but that's covered by schema. Overall solid.
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 all three parameters have descriptions. The description adds meaning beyond the schema by explaining the identifier can be a name, CIK, or filer ticker, and gives examples. It also clarifies that 'changes' diffs vs prior quarter, and 'limit' sets max positions. The description enriches the parameter semantics, pushing above 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 states a specific verb ('parsed', 'diffed') and resource ('13F portfolio', 'SEC information table') and clearly distinguishes itself from siblings. It names the input types (name, CIK, ticker) and the output detail (positions ranked, aggregated, options flagged, diffed). This unequivocally identifies the tool's function.
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 context on when to use it (when you need a fund's latest 13F holdings) and how to identify the fund (known name, CIK, filer ticker). It doesn't explicitly state when not to use it or name alternatives, but sibling tools like get_events, get_filings are sufficiently different. It lacks an explicit exclusion statement, but the input guidance is strong enough to steer an agent correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parsed SEC Form 4 insider trades for a ticker: owner, role, transaction code (P open-market purchase, S sale, A award, M exercise, F tax withholding), shares, price, dollar value, and a 10b5-1 plan flag. Code P is the only own-money buy signal; A/M/F are automatic compensation. Set form=3/5 for holdings statements or form=144 for notices of proposed sale (an intent-to-sell signal that precedes the Form 4). Pass ticker='latest' for the market-wide feed of the biggest open-market buys, or ticker='clusters' for companies where several insiders bought at once.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | For 'clusters': lookback window in days (default 15). | |
| form | No | Ownership form: 4 (trades, default), 3 (initial holdings), 5 (annual), or 144 (notice of proposed sale — an intent-to-sell signal that precedes the Form 4). | |
| limit | No | Number of results, 1-100 (default 20). | |
| ticker | Yes | US stock ticker (e.g. 'AAPL'), 'latest' for market-wide buys, or 'clusters' for cluster buys. | |
| min_insiders | No | For 'clusters': min distinct insiders (default 3). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds substantial behavioral context beyond that: it explains that code P is the only own-money buy signal, that A/M/F are automatic compensation, that form=144 is an intent-to-sell signal, and that 'latest' returns the biggest open-market buys. This significantly enriches the agent's understanding of the tool's behavior.
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 but packs dense, high-value information. It front-loads the core function in the first sentence, then explains transaction codes and special modes. Every clause earns its place; no filler or repetition.
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 5 parameters and no output schema, the description covers all major aspects: return fields, parameter behavior, special modes, and the meaning of transaction codes. It also mentions defaults for 'days' and 'min_insiders' implicitly through schema, and the description is self-sufficient for an agent to decide when and how to invoke 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?
Even though the schema covers 100% of parameters, the description adds meaning beyond the schema by explaining special values for 'ticker' ('latest' and 'clusters') and the semantic difference between form types. It also clarifies the business meaning of transaction codes, which is not in the schema. This raises the score well above 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 opens with a specific verb and resource: 'Parsed SEC Form 4 insider trades for a ticker'. It lists exact data fields (owner, role, transaction code, shares, price, dollar value, 10b5-1 flag) and distinguishes itself from siblings like get_filings by focusing on parsed insider transactions and offering unique special modes ('latest', 'clusters').
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 provides clear context for when to use each alternative: it explains the transaction code meanings (P vs A/M/F), directs users to form=3/5 for holdings statements and form=144 for proposed sales, and explains special ticker values 'latest' and 'clusters'. However, it does not explicitly name sibling tools or state when NOT to use this tool, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Margins, returns (ROE/ROA), leverage and liquidity ratios for a ticker, derived from SEC EDGAR fundamentals. Price-based ratios (P/E, P/B) excluded.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | US stock ticker, e.g. 'AAPL'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint) already indicate safe, non-mutating behavior. Description adds context about derivation source and excluded ratio types, beyond 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 sentences with no wasted words. First sentence lists ratio categories and source, second clarifies exclusion. Information is front-loaded.
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 retrieval tool with one parameter and no output schema, the description sufficiently covers included/excluded ratios and source, leaving no ambiguity.
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% with one parameter described as 'US stock ticker, e.g. AAPL'. Description adds no additional parameter details beyond the schema.
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 states it computes margins, returns (ROE/ROA), leverage, and liquidity ratios from SEC EDGAR fundamentals, and explicitly excludes price-based ratios (P/E, P/B). This distinguishes it from siblings like get_fundamentals.
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 explicit when-to-use or when-not-to-use guidance. Implied usage is for obtaining fundamental ratios, but alternatives like get_fundamentals are not compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Narrative sections from the latest 10-K/10-Q as clean text — Risk Factors (item 1A), MD&A (item 7), Business (item 1), etc. Built for LLM/RAG equity research. Omit 'item' to list the available sections first.
| Name | Required | Description | Default |
|---|---|---|---|
| form | No | Filing type: '10-K' (default) or '10-Q'. | |
| item | No | Section to fetch, e.g. '1A' (Risk Factors) or '7' (MD&A). Omit to list available sections. | |
| ticker | Yes | US stock ticker, e.g. 'AAPL'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is readOnly, openWorld, idempotent, and not destructive. The description adds clarity on behavioral traits: it retrieves the latest filing, returns 'clean text', and provides a listing mode when 'item' is omitted. This complements the annotations well, though some details like error handling are missing.
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 extremely concise—two sentences that front-load the core purpose and examples, followed by a specific usage hint. Every word earns its place, with no redundancy or irrelevant 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?
Given the lack of an output schema, the description could be more explicit about the return format (e.g., plain text, multiple sections at once). It implies a list when 'item' is omitted and a single section when provided, but this is not fully spelled out. The description is sufficient for basic usage but leaves some gaps for an AI agent.
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 parameters are well-documented. The description reinforces the behavior of omitting 'item' to list sections, which is already in the schema description for 'item'. It adds minimal new semantics beyond reminding the agent of this optional feature, resulting in a baseline score.
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 retrieves narrative sections from the latest 10-K/10-Q filings, listing specific items (Risk Factors, MD&A, Business). The verb 'get' matches the tool name, and the resource is distinctly different from sibling tools (company, events, filings, etc.), making its purpose unambiguous.
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 provides the useful hint to omit 'item' to list available sections, which helps the agent decide when to call without parameters. However, it lacks explicit guidance on when not to use this tool, prerequisites (e.g., valid ticker), or comparison to alternatives among siblings. The context is adequate but minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The company's subsidiaries and their jurisdictions of incorporation, parsed from Exhibit 21 of its latest 10-K. Best-effort parse of an HTML exhibit; empty for filers that list only significant subsidiaries or file no Exhibit 21.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | US stock ticker or CIK, e.g. 'AAPL'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds valuable behavioral context beyond annotations: it is a 'best-effort parse' and may return empty results when certain conditions apply. This helps set expectations without contradicting 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?
The description is two sentences with zero fluff. It front-loads the core purpose and then efficiently conveys the caveats. Every word 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 simple one-parameter read-only tool with rich annotations and a clear output concept, the description is complete. It covers what the tool returns, the source, and potential empty-result scenarios. Nothing an agent needs to call it correctly 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% for the single 'ticker' parameter, so the schema fully documents it. The description does not add additional parameter-level detail, but none is needed given the complete schema.
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 ('parsed'), resource ('company's subsidiaries'), and data source ('Exhibit 21 of its latest 10-K'). It clearly distinguishes this tool from siblings like get_filings or get_company, making its purpose unmistakable.
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 provides clear context: it is used to retrieve subsidiaries from a 10-K Exhibit 21, and even notes caveats (best-effort parse, may be empty). It does not explicitly exclude alternatives, but no sibling tool overlaps with this specific function, so the implied use case is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full XBRL-to-JSON converter. By default returns a company's normalized income statement, balance sheet and cash flow across every reported period, plus a concept index of every us-gaap/dei tag it reports. Pass concept to pull the raw time series for any specific tag(s) beyond the curated fundamentals; pass accession for every concept reported in one specific filing.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | No | SEC CIK, alternative to ticker. | |
| limit | No | Max periods per statement, 1-100 (default 40). | |
| period | No | Statement period (default annual). | |
| ticker | No | US stock ticker, e.g. 'AAPL'. | |
| concept | No | Comma-separated us-gaap/dei tag(s) to return the raw series for, e.g. 'Revenues,Assets'. Omit for normalized statements + concept index. | |
| accession | No | An accession (e.g. '0000320193-24-000123') to return every XBRL concept reported in that one filing. Overrides ticker/concept. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral context: default output spans every reported period, concept mode returns raw time series, and accession mode focuses on one specific filing. This goes beyond what annotations alone communicate.
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 compact and front-loaded, starting with the default behavior and then layering optional modes. The opening fragment 'The full XBRL-to-JSON converter' is slightly redundant with the title, but the rest of the description 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?
With no output schema, the description adequately explains the return shape: normalized statements, concept index, raw series, or per-filing concepts. It also communicates the override semantics for accession and the distinction from curated data. Minor gaps exist around data volume and the cik/ticker precedence, but these are covered by the 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 coverage is 100%, so a baseline of 3 applies. The description adds extra semantic value for `concept` and `accession` by explaining that concept pulls raw time series beyond curated fundamentals and accession captures every concept in a particular filing. This is meaningful enrichment over the schema text.
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 resource (SEC XBRL filings), a clear conversion action, and the default output: normalized income statement, balance sheet, cash flow, and a concept index. It also distinguishes the tool's modes from related data-pull tools by explaining the optional concept and accession behaviors.
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 context for when to use default mode versus passing `concept` or `accession`, including the purpose of each mode. It does not explicitly name sibling alternatives or when-not-to-use conditions, so it falls slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map any one of a ticker, CIK, or CUSIP to the canonical SEC entity: legal name, CIK, ticker(s), exchange, SIC industry and sector, state of incorporation, and location. The foundational lookup for identifying a filer.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | No | SEC CIK, e.g. '320193' (zero-padding optional). | |
| cusip | No | 9-character CUSIP, e.g. '037833100'. | |
| ticker | No | US stock ticker, e.g. 'AAPL'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate readOnlyHint, idempotentHint, openWorldHint, and non-destructiveness. The description adds useful behavioral context by listing the resolved fields (legal name, CIK, ticker(s), exchange, SIC, state of incorporation, location) and by clarifying that any one identifier maps to the same canonical entity.
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 focused sentences with no filler. The core action and accepted inputs lead, followed by the output payload and the tool's broader role. Every sentence adds 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 appropriately lists the resolved fields and frames the tool as a canonical lookup. It could further clarify whether multiple identifier parameters may be combined or how conflicts are resolved, but the essential call-and-response behavior is sufficiently covered.
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 baseline is 3, but the description adds semantic value by stating that the three identifier parameters are interchangeable entry points into the same entity resolution. This relationship among parameters is not expressed in the individual 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?
The description uses the specific verb 'Map' and names the exact resource ('canonical SEC entity') plus the three accepted identifier types. It enumerates the output fields, making the tool's purpose unmistakable and distinct from sibling data-retrieval tools.
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 frames the tool as 'The foundational lookup for identifying a filer,' which gives clear context for when an agent should use it. It does not explicitly name sibling alternatives or when-not-to-use conditions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the full text of every SEC filing since 2001 (the EDGAR full-text index). Returns matching filing documents with company, form, date, 8-K item codes, and a SEC.gov link. Quote a phrase for exact match; filter by form and date range.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query. Quote a phrase ("climate change") for an exact match; space-separated terms are ANDed. | |
| enddt | No | Only filings on/before this date, YYYY-MM-DD. | |
| forms | No | Comma-separated form filter, e.g. '8-K' or '10-K,10-Q'. | |
| limit | No | Results to return, 1-100 (default 20). | |
| offset | No | Pagination offset into the result set (default 0). | |
| startdt | No | Only filings on/after this date, YYYY-MM-DD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, the description adds useful context: it covers filings since 2001, returns a SEC.gov link, includes 8-K item codes, and describes exact-match behavior. It does not go into pagination or rate limits, but the safety profile is already established by 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?
Three sentences with the core purpose and scope front-loaded, followed by return format and query tips. Every sentence contributes information and none repeats the schema verbatim.
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?
Because there is no output schema, the description names the key returned fields (company, form, date, 8-K item codes, SEC.gov link), which is sufficient for an agent to interpret results. The remaining minor gap is that it does not describe pagination behavior, though limit and offset are fully documented in the 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%, so the input schema already documents every parameter. The description's 'quote a phrase' and 'filter by form and date range' guidance adds no new semantics beyond the schema definitions for q, forms, startdt, and enddt.
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 identifies a specific verb and resource: 'Search the full text of every SEC filing since 2001 (the EDGAR full-text index).' It also names concrete return fields. However, it does not explicitly explain how this differs from the sibling get_filings, leaving the distinction implicit.
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 via 'Quote a phrase for exact match; filter by form and date range,' which gives query tips. It never states when to prefer this tool over siblings such as get_filings, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Each tool targets a distinct SEC EDGAR resource and action: company info, filings, fundamentals, ratios, insider trades, activist stakes, fund holdings, events, and narrative sections. There is no overlap in purpose, and descriptions clarify any potential ambiguity (e.g., get_activist vs get_holdings).
All tools follow a consistent 'get_' prefix followed by a singular or plural noun (e.g., get_company, get_filings, get_ratios). The pattern is uniform and predictable, making it easy to infer behavior from the name.
Nine tools is well-scoped for a financial data server covering company profiles, regulatory filings, and derived metrics. Each tool has a clear, non-redundant role, neither feeling sparse nor bloated.
The surface covers the core EDGAR resources: company metadata, filings, financial statements, ratios, insider activity, activist filings, fund holdings, material events, and narrative sections. Minor gaps exist (e.g., direct search for specific filing types or proxy statements), but agents can accomplish most research workflows without dead ends.