Skip to main content
Glama

ko-mcp

by io.github.SharpLu

sec_get_filing_document

Get a source document from a SEC filing, served by ko.io. Returns a ko.io LINK to the rendered document (open in a browser) plus, optionally, an extracted text excerpt. Never returns the whole file — for full content, open the link or request a specific section.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cikYesCompany CIK number
fileNoFile name within the filing (from sec_get_filing_index). Omit for the primary document.
accession_noYesAccession number, e.g. '0000320193-23-000106'
include_excerptNoInclude a text excerpt (first ~6000 chars) in the response

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries full burden. It discloses key behaviors: returns a link, optionally an excerpt, never the whole file. It does not detail error handling or prerequisites but sufficiently explains the core behavior.

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?

Three sentences, no wasted words, front-loaded with purpose. Each sentence adds necessary information.

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's simplicity and no output schema, the description is fairly complete. It explains the return type (link) and behavior. Minor omissions like error handling or excerpt truncation details prevent a perfect score.

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 explaining that the 'file' parameter comes from sec_get_filing_index and that omitting it gets the primary document. It also clarifies the 'include_excerpt' parameter behavior.

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 'Get a source document from a SEC filing' and specifies it returns a link and optionally an excerpt. It differentiates from sibling tools like sec_get_filing_index and sec_list_filings by noting that it never returns the whole file.

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?

It provides clear context on what to expect (link, optional excerpt) and instructs users to open the link for full content. However, it does not explicitly name alternative sibling tools or state when not to use this tool.

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

All ko-mcp toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation5/5

Each tool targets a distinct resource and action, and descriptions explicitly disambiguate similar pairs (e.g., get_congress_member vs get_congress_trades, get_crypto_holder vs get_crypto_holders). No two tools appear to do the same thing.

Naming Consistency4/5

The dominant pattern is get_<noun>, with list_<noun> for enumerations. Minor deviations exist: a bare 'search' tool and the 'sec_' prefix on SEC filing tools break the uniform verb_noun style, but the pattern remains predictable.

Tool Count4/5

At 24 tools, this is on the heavier side, but the server spans multiple financial data domains (SEC filings, stocks, insider trading, crypto, rates, economics), so each tool has a clear purpose. It is just below the 'too many' threshold.

Completeness5/5

The tool surface is remarkably complete for financial data retrieval: SEC filing lifecycle is covered (list -> index -> document), institutional ownership is available from both stock and institution perspectives, and insider/congress/crypto/economic data are all present. No obvious gaps or dead ends.

Resources