Skip to main content
Glama

sec_get_filing_document

Read-onlyIdempotent

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. Requires a paid ko.io plan (Pro): on Free or keyless access the call returns an explicit plan-limit error. Use sec_list_filings / sec_get_filing_index (open on every plan) to find filings and their files.

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

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
cikYes
fileYes
linkYes
excerptYes
accession_noYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "accession_no": {
      +      "type": "string"
      +    },
      +    "cik": {
      +      "type": "string"
      +    },
      +    "excerpt": {
      +      "additionalProperties": false,
      +      "properties": {
      +        "chars_total": {
      +          "anyOf": [
      +            {
      +              "type": "integer"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ]
      +        },
      +        "status": {
      +          "enum": [
      +            "ok",
      +            "unavailable",
      +            "not_requested"
      +          ],
      +          "type": "string"
      +        },
      +        "text": {
      +          "$ref": "#/properties/file"
      +        },
      +        "truncated": {
      +          "type": [
      +            "boolean",
      +            "null"
      +          ]
      +        }
      +      },
      +      "required": [
      +        "status",
      +        "text",
      +        "chars_total",
      +        "truncated"
      +      ],
      +      "type": "object"
      +    },
      +    "file": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "link": {
      +      "additionalProperties": false,
      +      "properties": {
      +        "expires_at": {
      +          "$ref": "#/properties/file"
      +        },
      +        "signed": {
      +          "description": "true = ko.io-signed, expiring link a browser can open; false = needs a paid API key",
      +          "type": "boolean"
      +        },
      +        "url": {
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "url",
      +        "signed",
      +        "expires_at"
      +      ],
      +      "type": "object"
      +    }
      +  },
      +  "required": [
      +    "cik",
      +    "accession_no",
      +    "file",
      +    "link",
      +    "excerpt"
      +  ],
      +  "type": "object"
      +}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already provide readOnly/openWorld/idempotent/not-destructive hints. The description adds substantial behavioral context beyond that: it returns a ko.io link rather than the file, never returns full content, requires a paid Pro plan, and returns a plan-limit error on free/keyless access. No contradiction with annotations.

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 tight sentences: the first states the core purpose, the second states a key limitation, and the third covers plan requirements and alternative tools. No filler, with the most defining characteristics front-loaded.

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?

For a read-only retrieval tool that has an output schema, the description covers all essential non-schema behavioral facts: link vs. full content, excerpt availability, plan gating, and how to locate filings/files. An agent has everything needed to invoke the tool correctly.

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 description coverage is 100%, so the baseline is 3. The description adds minimal parameter-specific meaning beyond the schema; the note about requesting a specific section loosely relates to the 'file' parameter, but the schema already documents parameter purpose clearly.

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 ('Get') and resource ('source document from a SEC filing'), and immediately differentiates itself from sibling tools by naming sec_list_filings / sec_get_filing_index as the discovery path. It also clarifies that it never returns the whole file, further pinning down its scope.

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?

It explicitly tells the agent to use sec_list_filings / sec_get_filing_index (open on every plan) to find filings and their files, establishing when to use alternatives. It also discloses the paid-plan requirement and the explicit plan-limit error, so an agent knows when the call will fail and why.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.