Skip to main content
Glama
Sign In

Sec Financial Statements

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Note Text Search

note_text_search
Read-onlyIdempotent

Full-text search over tagged XBRL note/footnote text blocks — the disclosure prose behind the numbers (hedge notionals, commitment schedules, related-party narrative) that companyfacts/frames never expose. Give a search phrase; optionally narrow to one company or one note tag. This searches tagged NOTE BLOCKS only, not full filing text — for phrase search over the whole filing document use edgar_filing_text instead.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "interest rate swap"
    },
    "name": "note_text_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
tagNoOptional exact note tag to restrict to, e.g. "DerivativeInstrumentsAndHedgingActivitiesDisclosureTextBlock".
limitNoMax matches to return, 1-100 (default 20).
queryYesSearch phrase, e.g. "cross-currency interest rate swap notional".
companyNoOptional company name (ILIKE) to restrict the search to one filer.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, covering the safety profile. The description adds meaningful behavioral context beyond that: it searches tagged note blocks only, not full filing text, which sets a critical expectation about result scope. It does not discuss rate limits or result shape, but the annotation coverage lowers the bar.

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 that are fully front-loaded: purpose and data type first, usage instruction second, and the tool-boundary routing last. Every sentence earns its place with no redundancy.

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?

No output schema exists, yet the description conveys what the results conceptually contain (disclosure prose such as hedge notionals and commitment schedules). Combined with full schema coverage and rich annotations, the definition is nearly complete; only the concrete return format/pagination is left unspecified.

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 schema already documents all four parameters (query, tag, company, limit). The description only restates the filtering options ('optionally narrow to one company or one note tag') without adding syntax, matching behavior, or format details, so the baseline 3 applies.

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 (full-text search) plus a precise resource (tagged XBRL note/footnote text blocks), and clarifies the content type via concrete examples (hedge notionals, commitment schedules, related-party narrative). It explicitly distinguishes itself from companyfacts/frames and from whole-filing search, so an agent can identify it without opening a schema.

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?

Gives an explicit usage instruction ('Give a search phrase; optionally narrow to one company or one note tag') and a clear boundary with an alternative tool: note blocks only, and 'for phrase search over the whole filing document use edgar_filing_text instead.' The when-to-use and when-not-to-use conditions are both stated.

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

All Sec Financial Statements 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