Skip to main content
Glama

Sec Contract Text

sec_contract_text
Read-onlyIdempotent

Read the text of ONE SEC exhibit document — a credit agreement, merger agreement, indenture, employment agreement or any other EX-10 / EX-4 / EX-2 attachment — as clean plaintext, paged. Pass the document_url from sec_contracts_search or sec_contracts_by_company (or adsh + filename + the registrant's cik). Returns up to max_chars (default 50,000) from offset with truncated + next_offset for the next window; a very large exhibit (a syndicated credit agreement can run 2-4 MB of HTML) is read up to 4 MB and flagged raw_truncated. Use to quote the actual clause — the definition of "Change of Control", the severance multiple, the termination-fee amount, the interest-rate grid, the covenants — after sec_contracts_search located the agreement.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cikNoThe REGISTRANT's CIK (returned as `cik` on every search row). Needed with adsh + filename because the Archives path is keyed by the registrant, and the filing-agent CIK that prefixes many accession numbers does not resolve. Omit only when the accession prefix is the registrant itself.
urlNoThe exhibit's document URL on www.sec.gov/Archives, exactly as returned in `document_url` by sec_contracts_search. Preferred over adsh + filename.
adshNoAccession number, dashed or not (e.g. "0000712537-25-000088"). Use with `filename` and `cik`.
findNoOptional phrase to jump to: the page starts ~300 characters before its first occurrence instead of at `offset`. Use to land directly on the "Change of Control" definition or the "Termination Fee" section.
offsetNoCharacter offset to start from (default 0). Pass the prior result's next_offset to page forward.
filenameNoThe exhibit file name inside the filing, e.g. "fcf-ex103_20250331xchangeo.htm" (the part after the colon in a search hit's `_id`, also returned as `filename`).
max_charsNoMax characters in this page (1000-100000, default 50000).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, open-world access, so safety is covered. The description adds what the annotations cannot: paging mechanics via offset/next_offset, the `truncated` flag, and the 4 MB raw read cap with a `raw_truncated` flag for large HTML exhibits. That is substantive behavioral context beyond structured fields.

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?

Three dense, front-loaded sentences that lead with purpose and input sourcing before return mechanics. It is on the longer side and slightly repeats schema-documented details (defaults), but nearly every clause carries information an agent needs.

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?

There is no output schema, so the description must characterize returns, and it does: pagination via truncated/next_offset plus the raw_truncated size cap. For a paged fetch tool this is complete enough to call correctly without further reading.

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 the baseline is 3; the schema already documents each parameter including defaults. The description adds meaning by explaining the param interaction — how `find` pages relative to `offset`, the default `max_chars` of 50,000, and what `raw_truncated` implies — so it edges above baseline.

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?

States a specific verb and resource ('Read the text of ONE SEC exhibit document') and enumerates the covered exhibit types (EX-10/EX-4/EX-2). It cleanly distinguishes itself from the sibling searchers: they locate the agreement, this one retrieves its text.

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 instructs to source the `document_url` from sec_contracts_search or sec_contracts_by_company (or adsh+filename+cik) and states the trigger condition: 'Use to quote the actual clause ... after sec_contracts_search located the agreement.' Names the alternatives and the sequencing.

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.