Skip to main content
Glama

gateway

commentlettercheck__check_sec_comment_letters

Read-only

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.5/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint, openWorldHint), the description discloses that data is sourced live from SEC EDGAR, specifies the return shape (filing count and most recent filing date), and explicitly states what is not included. This exceeds what annotations already provide and gives an agent accurate expectations.

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 with no filler: the core purpose comes first, followed by output details and limitations. Every sentence earns its place and the description is easy to scan quickly.

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 simple one-parameter tool backed by rich annotationsrostered, the description is complete: it names the data source, the exact output fields, and the key exclusion. An agent knows what to expect in the response and how this differs from a paid report, with no missing context needed to invoke it 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?

The input schema already documents the single ticker parameter with an example (AAPL). The description only reinforces that the ticker is US-listed, which adds marginal value beyond the schema. Baseline 3 is appropriate given 100% schema coverage.

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 action ('Look up whether'), a clear resource ('US-listed ticker'), and precise scope ('SEC comment-letter correspondence... form types UPLOAD/CORRESP'). This clearly differentiates it from sibling tools that check accessibility, financial numbers, or other compliance topics.

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 clearly sets expectations: it returns a free-tier preview with only filing count and date, and explicitly excludes letter content or severity scoring. It does not name a specific sibling alternative, but the paid full report reference implies when richer detail would be needed.

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