SEC EDGAR financials, benchmarks, screening & Buffett value scans for agents. Pay x402 or API key.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.4/5 across 14 of 14 tools scored. Lowest: 2.8/5.
Each tool has a distinct purpose: quality scoring, valuation, raw facts, filings, financials, peer comparison, industry aggregates, insider activity, institutional ownership, market insights, screening, short pressure, and standard scores. No overlaps in functionality.
All tools use consistent snake_case naming with descriptive prefixes (e.g., company_, buffett_, market_). The pattern is predictable and helps infer tool purpose.
14 tools cover a broad range of SEC fundamentals without being overwhelming. Each tool serves a clear role, and the count is appropriate for a comprehensive financial data API.
Covers core areas: filings, financials, insider trades, institutional ownership, screening, scores, and market insights. Minor gaps (e.g., no direct analyst estimates or corporate events) but overall very well-scoped for the domain.
buffett_scanBInspectBuffett Quality Score (0-100) over a 5-year window: owner earnings, ROE consistency at 15%, balance-sheet safety, FCF quality. Foreign private issuers (20-F) excluded unless exclude_foreign=False. Not investment advice. Cost: $0.25.
| Name | Required | Description | Default |
|---|---|---|---|
| fy | No | ||
| limit | No | ||
| industry | No | ||
| min_score | No | ||
| min_revenue | No | ||
| exclude_foreign | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the cost ($0.25), states it's not investment advice, and mentions default exclusion of foreign issuers. However, it does not specify whether the tool is read-only, any rate limits, or authentication requirements.
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, concise and front-loaded with the core functionality. The first sentence explains the score and components, the second adds a filter, and the third adds a disclaimer and cost. Minimal waste, though could be slightly more 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 the tool has 6 parameters, no annotations, and an output schema, the description lacks completeness. It omits parameter explanations for 5 parameters and does not clarify expected inputs like fiscal year or industry filter. The cost and output schema help but are not sufficient.
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 must compensate. It only explains the 'exclude_foreign' parameter in context. The other five parameters (fy, limit, industry, min_score, min_revenue) are not described, leaving the agent without sufficient meaning for their usage.
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 that the tool computes a Buffett Quality Score (0-100) over a 5-year window based on owner earnings, ROE consistency, balance-sheet safety, and FCF quality. It distinguishes itself from siblings like 'buffett_value' and 'screen_companies' by specifying its unique scoring methodology.
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 does not provide guidance on when to use this tool versus alternatives. It only mentions that foreign private issuers are excluded by default unless 'exclude_foreign=False', but no comparative context or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
buffett_valueBInspectBuffett Value Scan: Quality Score fused with previous-close valuation — market cap, FCF yield, owner-earnings DCF margin of safety. Quality companies trading below intrinsic value. Foreign private issuers excluded unless exclude_foreign=False. Not investment advice. Cost: $0.25.
| Name | Required | Description | Default |
|---|---|---|---|
| fy | No | ||
| limit | No | ||
| industry | No | ||
| min_score | No | ||
| min_revenue | No | ||
| exclude_foreign | No | ||
| min_margin_of_safety | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the cost ($0.25) and that it's not investment advice, but does not detail data recency, error handling, or behavioral traits beyond the scanning logic.
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 concise (three sentences) and front-loaded with the core purpose. It efficiently conveys the tool's function and key details, though it could be slightly more 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?
The presence of an output schema reduces the need to describe return values. However, with 7 parameters mostly undocumented and limited behavioral transparency, the description is not fully complete for an effective scan 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 description coverage is 0%, so the description must explain parameters. It only addresses 'exclude_foreign' explicitly. Other parameters (fy, limit, industry, min_score, min_revenue, min_margin_of_safety) are not described, leaving a significant gap.
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 the tool as a 'Buffett Value Scan' that combines quality scores with valuation metrics to find undervalued companies. It specifies key criteria (market cap, FCF yield, margin of safety) but does not explicitly differentiate from the sibling 'buffett_scan'.
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 some context (exclusion of foreign issuers by default, cost, not investment advice) but lacks explicit guidance on when to use this tool versus alternatives like 'buffett_scan' or 'screen_companies'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
company_factsAInspectRaw normalized XBRL facts, filterable by canonical concept (revenue, net_income, total_assets, operating_cash_flow, ...), with filing provenance and quality flags. Cost: $0.01.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | Yes | ||
| limit | No | ||
| concept | No | ||
| fy_from | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description discloses a key behavioral trait: cost ($0.01). It also mentions output includes filing provenance and quality flags, which is useful for the agent. It does not cover authentication or rate limits but adds significant value beyond empty 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, well-structured sentence that front-loads the key information. Every word serves a purpose with no redundancy or unnecessary detail.
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?
While the output schema exists to cover return structure, the description omits explanation of temporal filtering (fy_from) and pagination (limit), which are relevant for correct usage. The main use case is covered, but gaps remain.
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 description adds concrete examples for the 'concept' parameter (e.g., revenue, net_income) which is not in the schema. However, it does not explain 'limit', 'fy_from', or 'cik'. With 0% schema description coverage, this partial compensation is notable.
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 'raw normalized XBRL facts' and mentions filtering by canonical concept, distinguishing it from sibling tools like company_filings or company_financials which handle filings or processed data.
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 raw XBRL fact retrieval with filtering but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. The sibling list provides context, but the description lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
company_filingsBInspectSEC filing index with direct document URLs; form filters by type (10-K, 10-Q, 8-K, ...). Cost: $0.005.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | Yes | ||
| form | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose all behavioral traits. It mentions the cost ($0.005) but does not describe rate limits, error handling, data freshness, or what happens when no results are found. The description is minimal.
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 with an appended cost note. It is front-loaded with the core purpose and contains no unnecessary words.
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 3 parameters and an output schema, the description gives the essential purpose and form filter. However, it lacks details on output structure (even though output schema exists) and does not address pagination or handling large result sets. It is adequate but has 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?
Schema description coverage is 0%, so the description must add meaning beyond the schema. It only partially explains the 'form' parameter by listing example types, but does not describe the 'cik' (required) or 'limit' parameters. No format or constraints are provided.
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 explicitly states the tool provides an SEC filing index with direct document URLs and mentions form filters by type (10-K, 10-Q, 8-K, ...). It clearly distinguishes from sibling tools like company_facts or company_financials by focusing on filings and document URLs.
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 given on when to use this tool versus alternatives (e.g., company_facts for detailed data, screen_companies for screening). It does not provide exclusions or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
company_financialsCInspectClean annual financial statements: revenue, margins, income, balance sheet, cash flow, and ratios (gross_margin, roe, fcf, ...) per fiscal year. cik = SEC CIK number (Apple=320193). Cost: $0.02.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | Yes | ||
| fy_to | No | ||
| fy_from | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must disclose all behavioral traits. Mentions $0.02 cost and 'clean' data, but misses read-only nature, rate limits, or authentication needs. Insufficient for a tool with no annotation safety net.
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 plus cost note; front-loaded with main purpose. Minimal waste, but could be more precise about the verb (e.g., 'provides' instead of 'Clean').
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?
Output schema exists, so return values are covered. However, lacks context on data range (e.g., how many years), pagination, or meaning of 'clean'. Adequate but not thorough.
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 has 0% description coverage. Description explains cik with example but does not describe fy_to and fy_from parameters (presumably fiscal year range). Leaves agent guessing about optional parameters.
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 specifies retrieving clean annual financial statements with details on revenue, margins, etc., and provides the CIK example. It distinguishes from sibling tools like company_facts and company_filings by focusing on financial statements.
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?
Only provides an example CIK and cost, but no guidance on ideal use cases, when to avoid, or alternatives among siblings like compare_to_peers or screen_companies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
company_signalAInspectComposite factor scorecard: quality, value, insider conviction, institutional positioning and short sentiment, each 0-100, plus a renormalized composite and coverage figure. Includes institutional ownership %, insider buy intensity (bps of market cap), short-to-ADV, and governance flags. weights is optional JSON, e.g. {"quality":0.4}. RESEARCH SIGNAL, NOT INVESTMENT ADVICE. Cost: $0.05.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | Yes | ||
| weights | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It adds useful context such as the $0.05 cost, 'RESEARCH SIGNAL, NOT INVESTMENT ADVICE' disclaimer, and optional weights input. However, it lacks details on error handling, data sources, or access requirements, and does not explicitly state that it is a read-only operation.
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 concise and front-loaded with the core purpose. It includes essential operational details (weights format, cost, disclaimer) without unnecessary fluff. The list of included metrics is slightly dense but still organized.
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?
The output schema likely covers return values, and the description lists the key components, providing a reasonable overview. However, the missing cik documentation and lack of guidance on when to use this tool relative to sibling tools create gaps for an agent to invoke it 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?
Schema description coverage is 0%, so the description must compensate. It explains the optional 'weights' parameter with a concrete JSON example, but completely omits the required 'cik' parameter, leaving its meaning and format undocumented. This is a significant gap for the primary input.
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 the tool as a 'Composite factor scorecard' and enumerates the specific factors (quality, value, insider conviction, institutional positioning, short sentiment) and outputs (0-100 scores, composite, coverage). This distinguishes it from sibling tools that target individual signals.
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 use for aggregate scoring through the term 'composite factor scorecard' but does not explicitly state when to choose this tool over alternatives like insider_activity or short_pressure. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_to_peersBInspectCompare one company's metrics against its industry cohort percentiles. Cost: $0.05.
| Name | Required | Description | Default |
|---|---|---|---|
| fy | Yes | ||
| cik | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions cost ($0.05), which is a behavioral trait. However, without annotations, it lacks information on side effects, auth requirements, or rate limits. For a read-only comparison tool, this is adequate but not thorough.
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 very concise (two sentences) and front-loaded with the purpose. It could include more detail, but it is not verbose.
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 an output schema present, the description need not explain return values, but it fails to describe what metrics are compared or how percentiles are computed. Parameter documentation is missing, making the tool hard to use without external knowledge.
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%, and the description does not explain the parameters (cik and fy). Users are left to infer that cik is a company identifier and fy is a fiscal year, but no details are provided.
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: comparing one company's metrics against its industry cohort percentiles. It uses a specific verb (compare) and resource (metrics vs. percentiles), distinguishing it from sibling tools like industry_aggregate or standard_score.
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 on when to use this tool versus alternatives. Sibling tools include many similar financial analysis tools (e.g., industry_aggregate, standard_score), but the description provides no context for choosing compare_to_peers over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
industry_aggregateBInspectCross-company cohort percentiles (p10/p25/median/p75/p90) for a metric, by industry (2-digit SIC) and size bucket. Metrics: gross_margin, operating_margin, roe, rd_intensity, debt_to_equity, revenue, fcf, ... Cost: $0.05.
| Name | Required | Description | Default |
|---|---|---|---|
| fy | No | ||
| size | No | ||
| metric | Yes | ||
| industry | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description adds some behavioral context: percentiles computed, metrics list, cost. Lacks details on data coverage, missing values, or response structure (though output schema exists). 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?
Concise single sentence with list and cost note. No unnecessary words, but could be more structured with parameter hints.
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 tool complexity and output schema existence, description covers core functionality but omits details on optional parameters (fy, industry format). Adequate for basic use but incomplete for advanced usage.
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 description must compensate. It only describes 'metric' (example list) and implies 'industry' (2-digit SIC) and 'size bucket'. Parameter 'fy' is not mentioned, and 'size' is vague. Insufficient to fully guide parameter usage.
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 that it provides cross-company cohort percentiles for a metric by industry and size bucket, listing example metrics. It is specific about the resource (percentiles) and grouping, but does not differentiate from sibling tools explicitly.
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?
Implies usage when industry aggregate percentiles are needed, and mentions cost ($0.05) as a constraint. However, no explicit when-to-use vs alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
insider_activityBInspectRecent insider (Form 4) transactions for a company plus a trailing summary: open-market buys vs sales, distinct buyers, net dollar value, with 10b5-1 plan flags. Cluster buying by officers/directors is a studied positive signal. Not investment advice. Cost: $0.02.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | Yes | ||
| months | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses cost ($0.02) and disclaims 'Not investment advice', but does not mention read-only nature, data freshness, rate limits, or any destructive potential. The trailing summary is described, adding some value.
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 a short note, efficiently conveying the tool's purpose and output. It front-loads the core functionality. However, it could be slightly more structured by separating parameter guidance.
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 0% schema coverage and lack of parameter descriptions in the tool definition, the description is incomplete. It does not explain what cik or months represent, leaving the agent to guess. The presence of an output schema partially mitigates missing return value documentation.
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 0% (no parameter descriptions in schema). The description does not explain the two parameters: cik (required integer) and months (optional integer, default 12). Without context, the agent cannot infer what values are appropriate for these parameters.
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 insider Form 4 transactions and provides a trailing summary with metrics like open-market buys/sales, net dollar value, and 10b5-1 plan flags. It distinguishes from sibling tools by specifying 'insider (Form 4)' and 'open-market buys vs sales', which is not covered by tools like institutional_ownership.
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 insider trading analysis and mentions cluster buying as a positive signal, but does not explicitly state when to use this tool versus alternatives (e.g., institutional_ownership). No guidance on when not to use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
institutional_ownershipAInspect13F institutional ownership snapshot: number of holders, aggregate shares/value, and quarter-over-quarter change (accumulating vs trimming). 45-day reporting lag; long-only. Not investment advice. Cost: $0.02.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description bears full responsibility for behavioral disclosure. It mentions the 45-day reporting lag, long-only nature, cost ($0.02), and that it is not investment advice. This fully informs an agent about the tool's characteristics without contradicting any 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 concise (three sentences) and front-loaded with the most important information: what the tool returns (number of holders, aggregate shares/value, QoQ change). It then adds relevant context (lag, asset class, cost) without unnecessary elaboration. 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?
Given the tool has an output schema (not shown), the description adequately overviews the return values. It mentions key context: lag, long-only, cost. However, it lacks explicit mention that the snapshot is for the most recent available quarter and does not specify that the cik parameter is required. This leaves minor gaps in completeness.
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 0% description coverage; the only parameter 'cik' is not described. The tool description does not mention the parameter or its role (e.g., the CIK number identifying the company). While the name 'cik' is standard, the description fails to add meaning beyond the bare schema, which is insufficient given the low schema coverage.
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 is a '13F institutional ownership snapshot' with specific data points: number of holders, aggregate shares/value, and quarter-over-quarter change. This distinguishes it from sibling tools like insider_activity or short_pressure, which cover different financial data.
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 institutional ownership data with a 45-day reporting lag and long-only focus, helping an agent decide whether this tool is appropriate for a given query. However, it does not explicitly state when to use this tool versus alternatives like company_facts or industry_aggregate, which might also provide ownership-related information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_insightsAInspectCatalog of curated market-wide analyses with parameters. FREE. Call before market_insight / buffett_* to see options.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions it is 'FREE' but lacks other behavioral details (e.g., rate limits, caching). Since it is a simple read-only tool with no annotations, minimal disclosure is acceptable.
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 front-loaded sentences with no wasted words, conveying purpose, cost, and usage guidance efficiently.
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?
Tool is simple; description covers purpose and usage context. Output schema exists, so return format details are not required. Slightly incomplete: does not explicitly state what the catalog returns, but sufficient for the tool's 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?
Tool has no parameters, input schema coverage is 100%, and description does not need to add parameter details; baseline of 4 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?
Description clearly states it is a 'catalog of curated market-wide analyses' and instructs to call before specific sibling tools (market_insight, buffett_*), making the tool's purpose and differentiation evident.
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 says 'Call before market_insight / buffett_* to see options,' providing direct when-to-use guidance relative to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
market_insightCInspectCurated analysis across all companies. name: top_companies, movers, sector_landscape, metric_trend (agg=sum|median|mean), capital_returns, filing_velocity. Cost: $0.15.
| Name | Required | Description | Default |
|---|---|---|---|
| fy | No | ||
| agg | No | ||
| form | No | ||
| name | Yes | ||
| fy_to | No | ||
| limit | No | ||
| metric | No | ||
| months | No | ||
| fy_from | No | ||
| industry | No | ||
| min_revenue | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior but only mentions cost ($0.15). It does not describe side effects, error handling, caching, or what happens with invalid names. The phrase 'curated analysis' is vague.
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 short (two sentences) and front-loaded with purpose. It lists names concisely. However, it could be slightly more structured by grouping parameters per analysis type.
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 complexity (11 parameters, multiple named analyses) and lack of schema descriptions, the description is insufficient. It does not explain how parameters interact with different names or provide guidance on usage patterns. The output schema exists but is not described.
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 description adds meaning for the 'name' parameter (listing valid values) and partially for 'agg' (in context of metric_trend). However, with 11 parameters and 0% schema description coverage, the description fails to explain other critical parameters like fy, form, limit, industry, etc.
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 provides 'curated analysis across all companies' and lists specific analysis types (top_companies, movers, etc.), which distinguishes it from sibling tools like company_facts or company_financials. The verb is implicit but the resource (market insight types) is clear.
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 aggregate market analysis via the listed names, but does not explicitly state when to use this tool versus alternatives like industry_aggregate or screen_companies. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
screen_companiesAInspectScreen companies by financial criteria. filters is a JSON list of [metric, op, value] triples, e.g. [["gross_margin",">",0.6],["revenue",">",1e9]]. Cost: $0.10.
| Name | Required | Description | Default |
|---|---|---|---|
| fy | Yes | ||
| limit | No | ||
| filters | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the cost ($0.10) and explains the filter format. However, it does not describe the output, auth needs, or rate limits, which are important behavioral traits for a query 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?
The description is two sentences, front-loading the purpose and immediately providing a concrete example. No unnecessary words 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?
Given 3 parameters, no annotations, and an output schema, the description covers usage of 'filters' thoroughly but omits 'fy' and 'limit'. The cost is helpful, but the lack of param descriptions reduces completeness.
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 0%, so parameters are undocumented in the schema. The description explains the 'filters' parameter format with an example, adding value, but fails to explain 'fy' and 'limit' parameters, leaving significant gaps.
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 'Screen companies by financial criteria,' which is a specific verb-resource pair. It distinguishes from sibling tools like 'company_financials' and 'compare_to_peers' by focusing on screening multiple companies based on filter criteria.
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 an example of the filter format and mentions cost, which guides usage. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
short_pressureAInspectShort-selling pressure: FINRA daily short-volume ratio over ~20 trading days — a bearish-sentiment proxy. Daily short-sale volume, not bi-monthly short interest. Not investment advice. Cost: $0.02.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description covers data source (FINRA), time window (~20 trading days), and cost ($0.02), but lacks details on data freshness, rate limits, or error handling for invalid CIK. Adequate but not thorough.
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 with no redundancy. Key information (what, data source, time window, cost, disclaimer) is front-loaded 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 the single parameter and output schema existence, the description covers the tool's nature, data source, and cost adequately. Missing explanation of CIK parameter slightly reduces completeness for a data 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?
Only one parameter (cik) with no schema description. The description does not explain what CIK is or how it is used, leaving the agent to infer from context. With 0% schema coverage, the description fails to compensate.
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 provides a short-selling pressure metric using FINRA daily short-volume ratio over ~20 days as a bearish-sentiment proxy. It distinguishes itself from bi-monthly short interest, making the 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 implies bearish-sentiment analysis but does not explicitly mention when to use this tool versus alternatives like insider_activity or market_insight. The disclaimer 'Not investment advice' is present but no direct usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
standard_scoreBInspectIndustry-standard fundamental scores over all US public companies. name: piotroski (F-Score 0-9), altman_z (bankruptcy zones), beneish_m (earnings-manipulation flag), magic_formula (Greenblatt rank), accruals (Sloan earnings quality). Peer-reviewed; not investment advice. $0.15.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| zone | No | ||
| limit | No | ||
| worst | No | ||
| min_score | No | ||
| min_revenue | No | ||
| flagged_only | No | ||
| exclude_foreign | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions peer-reviewed and cost, but fails to disclose key behaviors like return format, pagination, or how parameters affect results. This is inadequate for a tool with 8 parameters.
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 short and front-loaded with the main purpose. However, the bullet-like listing of score names could be more concise or moved to the schema. Overall, it is efficient but with minor waste.
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 8 parameters and an output schema, the description should provide more context on how parameters interact and what results look like. It only covers the name parameter, leaving the tool's overall behavior under-specified.
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 description must compensate. Only the 'name' parameter is explained by listing its options. The other 7 parameters (e.g., limit, zone, min_score) have no explanation at all, failing to add meaning 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?
The description clearly states it provides 'industry-standard fundamental scores' and lists specific score names (piotroski, altman_z, etc.), which identifies the resource and verb. It distinguishes from sibling tools which are other financial analysis 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 implies usage by listing available scores but does not explicitly state when to use this tool vs alternatives. No when-not or comparison with sibling tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
top_signalsBInspectRank companies by composite factor score across five evidence sources. min_coverage filters thinly scored names; weights re-weights the factors. RESEARCH SIGNAL, NOT INVESTMENT ADVICE. Cost: $0.25.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| weights | No | ||
| min_coverage | No | ||
| min_composite | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds helpful context by mentioning the cost ($0.25) and the research-signal disclaimer, and explains the effect of min_coverage and weights. However, it does not disclose data freshness, rate limits, or any other limitations beyond the disclaimer, so transparency is partial but not comprehensive.
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 concise and front-loaded: the first sentence states the core function, the second clarifies two important parameters, and the third provides cost and risk disclaimers. Every sentence serves a purpose with no fluff or redundancy. It is appropriately sized for the tool's complexity.
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?
The description provides a clear purpose, explains some parameters, and includes cost and disclaimers. Return values are covered by the output schema, so that is not needed. However, it lacks usage guidelines and does not clarify how this tool differs from sibling tools like screen_companies or standard_score. This leaves an agent uncertain about when to select this 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?
The schema description coverage is 0%, so the description must compensate. It provides meaningful explanations for min_coverage ('filters thinly scored names') and weights ('re-weights the factors'). However, limit and min_composite are not explained, leaving a gap. The partial coverage of two out of four parameters makes this a 3.
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: ranking companies by a composite factor score across five evidence sources. It uses a specific verb 'Rank' and identifies the resource, but it does not explicitly differentiate from sibling tools like screen_companies or standard_score, so it lacks explicit sibling differentiation.
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 no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, use cases, or exclusions. The disclaimer 'RESEARCH SIGNAL, NOT INVESTMENT ADVICE' is a risk notice, not usage guidance. Without alternatives or context, the agent is left to guess when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
