SEC EDGAR MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct aspect of SEC data: monitoring, company profiles, metadata search, full-text search, filing retrieval, section reading, comparison, ownership, trends, company screening, fund analysis, proxy statements, and financial notes. The descriptions clearly differentiate overlapping tools like edgar_search vs. edgar_text_search.
Naming Consistency5/5
All tools follow the consistent pattern 'edgar_<word>' with a mix of nouns and verbs. The naming is predictable and intuitive (e.g., edgar_filing, edgar_read, edgar_compare).
Tool Count5/5
With 13 tools, the set is well-scoped for an SEC filings server. Each tool covers a specific task without overlap, and the count is appropriate for the domain's complexity.
Completeness5/5
The tool set comprehensively covers SEC-related tasks: monitoring, searching, retrieving, reading, comparing, analyzing ownership, trends, screening, fund analysis, proxy, and financial notes. There are no obvious gaps for the intended use case.
Average 4.2/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the tool's functionality and return types, but does not disclose behavioral traits like authentication needs, rate limits, or error handling for invalid inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organised with bullet points and examples, making it easy to read. While slightly lengthy due to examples, it remains efficient and front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 covers the tool's purpose, parameter usage, and typical return content. It lacks mention of error responses or edge cases, but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds value beyond the schema by explaining parameter combinations, the detail parameter's effect, and providing concrete examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool examines any SEC filing and returns structured context. It provides examples and mentions key data types, but does not explicitly differentiate from sibling tools like edgar_read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description details two ways to specify a filing with examples, offering clear context on parameter usage. However, it does not specify when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose behavioral traits such as read-only nature, error handling, rate limits, or what happens with invalid identifiers. Only usage behavior is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs, front-loaded with purpose, followed by succinct examples. Every sentence is meaningful and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description does not explain return format, pagination, or error states. Adequate for a simple tool but could be more complete regarding expected output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so schema already documents parameters. The description adds value by explaining the relationship between identifier and analysis_type with examples, but does not significantly extend beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for insider trading (Form 4) and institutional fund portfolios (13F), with specific analysis_type values. It distinguishes from sibling tools by focusing on these specific data sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (insider trades or fund portfolios) and provides examples for each use case, including correct identifier format and analysis_type. No explicit when-not-to, but the examples serve as clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the tool as returning data (profile, financials, etc.) and how to control inclusion, implying a read operation. It does not explicitly state read-only, but the behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, front-loaded with the primary purpose, and includes concise examples. Each sentence adds value, though it could be slightly more terse without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the returned data types and customization. It covers all key parameters and usage scenarios, though it omits error handling or limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. The description adds value through examples (e.g., 'identifier="AAPL"', 'include=["financials"]') and explains default behavior, improving parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is the starting point for company-level questions, returning profile, financials, filings, and ownership. It distinguishes itself from siblings as a comprehensive entry point, but does not explicitly contrast with each sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this as the starting point for any company-level question,' providing clear when-to-use guidance. However, it does not specify when not to use or provide alternative tools for specific cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It describes the tool's action but omits behaviors like conflict handling when both 'identifiers' and 'industry' are provided, output format, or data freshness. Adequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct: a single sentence defining the tool followed by three concise examples. No filler, front-loaded with core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with two major modes, the description covers the key use cases. It lacks mention of conflict resolution between inputs and output details (no output schema), but is otherwise complete for the primary scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 6 parameters. The description adds real usage examples but does not clarify mutual exclusivity of 'identifiers' and 'industry' or explain parameter interactions beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool compares companies on financial metrics or analyzes an industry sector with peer selection. Examples clearly distinguish it from siblings like edgar_company (single company) and edgar_screen (filtering).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use cases with examples (company comparison vs. industry analysis). It does not explicitly exclude conflicting inputs or name alternatives but the usage contexts are well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that feed is updated every few minutes, returns latest filings, and limit has maximum of 100. With no annotations, this provides sufficient behavioral insight for a non-destructive monitoring tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with a clear structure: one-line purpose, update frequency, then bulleted examples. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple monitoring tool with no output schema, the description adequately covers key aspects (filtering, limit, update cadence). Lacks explicit return format, but examples imply list of filings; sufficient for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds marginal value beyond schema. Examples show valid form values and default/max for limit, but does not provide new semantic information beyond what schema already includes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns latest SEC filings from today's live feed, using specific verbs (see, returns). It distinguishes from siblings by focusing on real-time monitoring rather than historical search or company-specific tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage guidance with examples for common scenarios (all filings, 8-Ks, insider trades, etc.). Lacks explicit when-not-to-use or comparisons with sibling tools, but the context strongly implies its purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the kind of data extracted (tables, metrics, governance data) but does not mention that the tool is read-only, any required permissions, rate limits, or response format. The examples suggest it retrieves static data, but this is implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear purpose statement followed by practical examples. Every sentence serves a purpose: the first defines the domain, the second lists extracted items, and examples show parameter usage. No redundant or irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters (both well-documented in schema) and no output schema, the description adequately covers the input. However, it could be more complete by describing the output format or indicating if it returns structured data or raw text. The examples give hints but not a full specification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds value by clarifying the 'filing_index' parameter with '0=latest, 1=previous' in examples, which is not in the schema description. It also demonstrates usage patterns for 'identifier' with tickers like AAPL and MSFT.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for CEO compensation, executive pay, and corporate governance questions, with specific actions like extracting compensation tables and pay-vs-performance metrics. This distinguishes it from siblings like 'edgar_monitor' or 'edgar_company' by focusing exclusively on proxy statements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use the tool (compensation and governance questions) and provides concrete examples for CEO pay and compare pay. However, it does not explicitly state when not to use it or mention alternative tools for other SEC filings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 default and max limit (20, max 50) for the limit parameter, which is helpful. However, it fails to disclose other behavioral traits like rate limits, pagination behavior, or any restrictions on query complexity. The description could be more transparent about expected behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and uses a bullet list for examples. Every sentence adds value. However, slightly longer than necessary due to the example list, but this is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain the return format or what fields are returned per result. For a search tool, the agent needs to know what information is in the response (e.g., filing IDs, excerpts, relevance scores). The description provides good input guidance but lacks output context. Sufficient for basic use but incomplete for complex workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value beyond schema by showing concrete usage examples (e.g., forms, dates, identifier). This helps the agent understand how to combine parameters effectively. The examples demonstrate the semantics well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches the actual text content of SEC filings via EDGAR's full-text search index, and explicitly distinguishes from edgar_search which only searches metadata. The verb+resource is specific and differentiates from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage examples (topic search, 8-K events, date range, company-specific) and explicitly contrasts with edgar_search, telling the agent when to use this tool vs the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It transparently lists all actions with examples, making the tool's behavior clear. It does not disclose error handling or rate limits, but the read-only nature is inferred from the actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient and front-loaded with the tool's purpose. It uses a list of action types and examples, making it scannable. However, some minor redundancy could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the available actions and example usage. However, it lacks details on return format, pagination (limit parameter), and error cases. Given no output schema, more context on response would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant value by providing concrete examples for each action and parameter combination, demonstrating usage beyond the schema's simple descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for mutual fund, ETF, BDC, and money market fund analysis, with specific actions listed. It distinguishes from sibling tools like edgar_company and edgar_filing by focusing solely on fund-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this for ... fund analysis,' providing clear context for when to invoke the tool. It does not explicitly mention when not to use it or point to alternatives, but the sibling list implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes what the tool returns: narrative text, statement line items it explains, and structured table data. Also explains detail levels (minimal, standard, full). No annotations provided, so the description carries full burden; it adequately discloses behavior without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs plus bullet-style examples. Every sentence adds value, with the first sentence immediately stating purpose. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and simple return structure, the description covers return types (narrative, tables) and detail levels. Missing are error cases and rate limits, but for a read-only document retrieval tool this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by providing examples of topic values (debt, revenue, leases) and clarifying that omitting topic gives a table of contents. This enriches the parameter meaning beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'drill into' and identifies the resource as 'notes and disclosures' behind financial statement numbers. It clearly distinguishes from sibling tools like edgar_read or edgar_filing by focusing on explanatory notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when you need to explain WHY a number is what it is' with concrete examples (debt terms, revenue recognition). Does not explicitly state when not to use, but the context and examples imply it is for notes, not for raw filings or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'instant results, no API calls', which gives insight into performance and dependencies. It also says filters can be combined. Since no annotations exist, the description takes on the burden, and these details help the agent understand behavior. However, it does not mention ordering, pagination, or what happens if no matches are found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It starts with a clear purpose sentence, then a note about instant results, followed by five bullet-point examples. Every sentence is informative and earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 optional parameters and no output schema or annotations, the description covers the tool's functionality well. It explains the data source (SEC reference) and shows parameter combinations. However, it could mention the structure of returned results or any limitations, but it is sufficiently complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are documented in the schema with descriptions, but the description adds value by providing concrete examples for each parameter (e.g., sic=2834, industry='software', exchange='NYSE'). It also explains that 'industry' searches SIC descriptions, which is not in the schema. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is used to 'discover or screen companies by industry, exchange, or state', and specifies that it returns matching companies from SEC reference data. The examples further reinforce the purpose without ambiguity, and it differentiates from siblings like edgar_search, edgar_company, etc., by focusing on screening rather than searching filings or company details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to discover or screen companies' and provides context on when to use it. It includes examples of filtering by industry, SIC, exchange, and state, and notes that filters can be combined. However, it does not mention when not to use this tool or point to alternative tools for related tasks, missing some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the tool extracts narrative content and lists available sections per form type. It implies read-only behavior but does not detail edge cases like conflicting parameters or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with bullet points and examples. Each sentence adds value, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the workflow, section availability, and examples. It lacks clarification on behavior when both identifier and accession_number are provided, and does not describe the return format. Overall, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds significant value by providing a detailed list of available sections per form type, usage guidance for identifier vs accession_number, and examples that clarify param combinations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads text content of specific sections from a filing, distinguishing it from siblings like edgar_filing (which identifies filings) and edgar_text_search (which searches text). It provides a specific verb and resource, and includes form-specific section lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use edgar_filing first to identify a filing before using edgar_read, and provides examples for different forms. It does not explicitly state when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It states the tool 'returns XBRL-sourced time series with growth rates', implying a read-only retrieval operation. While it doesn't specify side effects, authentication, or rate limits, the read-only nature is sufficiently clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: first sentence states purpose, then returns details, followed by relevant examples. Every sentence is useful with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains output as 'time series with growth rates'. Combined with the schema (which documents all parameters including defaults), the tool is fully understandable. Examples further clarify usage patterns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by showing parameter combinations through examples (e.g., 'identifier="AAPL", concepts=["revenue"]'), enhancing understanding beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'financial trend analysis over time' and specifies 'returns XBRL-sourced time series with growth rates', distinguishing it from siblings like edgar_company or edgar_filing which focus on other aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this for financial trend analysis over time' and provides concrete examples covering different use cases (single metric, multi-metric, quarterly), giving clear guidance on when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It correctly states it searches metadata, not filing text, implying safe read-only behavior. Could mention lack of authentication needs or pagination, but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured, front-loaded with purpose and examples. No unnecessary sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Good for a search tool with 5 optional parameters and no output schema. Examples cover typical use cases. No missing critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 5 parameters (100% coverage), so baseline 3. Description adds contextual examples and clarifies search scope (metadata vs. text), enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool searches metadata (names, form types, dates) for companies or filings, differentiating from edgar_text_search. Verb+resource is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit examples for different search types and a clear alternative (edgar_text_search) for full-text content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![sec-insight-mcp MCP server](https://glama.ai/mcp/servers/NiharKalsekar099/sec-insight-mcp/badges/card.svg)](https://glama.ai/mcp/servers/NiharKalsekar099/sec-insight-mcp)

Score Badge

Copy to your README.md:

[![sec-insight-mcp MCP server](https://glama.ai/mcp/servers/NiharKalsekar099/sec-insight-mcp/badges/score.svg)](https://glama.ai/mcp/servers/NiharKalsekar099/sec-insight-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/NiharKalsekar099/sec-insight-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server