Skip to main content
Glama
Sign In

Edgar & Edgarette: SEC Filing Boards

by io.github.HuangGoodmanAgency
OverviewDiscussionsAdmin

Company card: an actuarial reading of any SEC filer

get_company_performance
Read-onlyIdempotent

Edgar & Edgarette performance card for any SEC filer (name, ticker or CIK): recent filings, then an actuarial-style reading of its audited 10-K figures (exposure, experience, credibility, an if-the-pace-held range, cautions). Every figure is the company's own, from SEC EDGAR, with source links. Reporting, not investment advice. From POPS4; confirmations: Jenny Huang Goodman MPA MSc MHSA, Principal.

Input Schema

NameRequiredDescriptionDefault
priceNooptional share price YOU supply. Adds price/earnings, price/book, price/sales, dividend yield and market value, computed from that price and the company's filed per-share figures. The price is never stored or published; the card sources none.
companyYescompany name, ticker or CIK

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / price
      Added value: +{
+  "description": "optional share price YOU supply. Adds price/earnings, price/book, price/sales, dividend yield and market value, computed from that price and the company's filed per-share figures. The price is never stored or published; the card sources none.",
+  "type": "number"
+}
  2. First observed

TDQS

B3.2/5.0
Behavior4/5

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

Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds meaningful context beyond annotations: figures come from SEC EDGAR with source links, the user-supplied price is never stored or published, and the output is reporting rather than investment advice. It still omits latency, error behavior, and precise return structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the text is bloated with branding ('Edgar & Edgarette'), actuarial jargon, and a credential/contact sentence ('From POPS4; confirmations: Jenny Huang Goodman...') that does not help an agent invoke the tool. Several phrases could be removed without losing call-relevant meaning.

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?

With no output schema, the description does a reasonable job of describing what the card contains: recent filings, exposure, experience, credibility, a pace-held range, cautions, and source links. For a read-only reporting tool, this is nearly complete, though it does not specify response format or organization.

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 both parameters are documented in the schema, including the detailed optional price parameter. The description largely repeats the company identifier formats (name, ticker, CIK) rather than adding syntax or validation meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource and scope: a performance card for any SEC filer using name, ticker, or CIK, returning recent filings plus an actuarial-style reading of 10-K figures. It is clear what the tool produces, but it does not explicitly differentiate itself from siblings such as watch_company or price_program.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to use this tool versus alternatives like watch_company or price_program, nor are there exclusion conditions. The closest signal is the implicit use case of generating a company card, but an agent must infer routing on its own.

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

All Edgar & Edgarette: SEC Filing Boards toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources