Skip to main content
Glama

check_sec_comment_letters

Look up whether a US-listed ticker has any SEC comment-letter correspondence on file (staff review letters and company responses, form types UPLOAD/CORRESP). Returns a free-tier preview: filing count and most recent filing date, sourced live from SEC EDGAR. Does not include letter content or severity scoring -- that's the paid full report.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tickerYesA US-listed stock ticker symbol, e.g. AAPL

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/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 discloses the live SEC EDGAR source, the preview fields returned (filing count and most recent filing date), and exclusions such as no letter content or severity scoring. This is transparent about both behavior and limitations.

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, each earning its place: purpose and scope, output and data source, then explicit limitations. Information is front-loaded and there is 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?

For a single-parameter read-only lookup with no output schema, the description supplies the essential return values, data source, and exclusions. Nothing an agent needs to select or invoke the tool correctly is missing.

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%, and the only parameter 'ticker' is already described as a US-listed stock ticker. The description mirrors that meaning but adds no new parameter constraints or usage nuance 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 uses a specific verb ('Look up') with a clearly defined resource: whether a ticker has SEC comment-letter correspondence, including form types UPLOAD/CORRESP. It also distinguishes what this tool is for by noting it returns only a preview, not full report content.

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 states when to use the tool: to check existence and get basic filing metadata. It explicitly says what it does not provide (letter content, severity scoring) and points to the paid full report for that, giving clear usage boundaries.

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.

Resources