Skip to main content
Glama
Sign In
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

congress_report

Fetch and parse a US Senate congressional disclosure report from a filing URL, returning filer, filing date, report parts, and transactions; supports annual, periodic transaction, and extension notice filings.

Instructions

Fetch and parse a congressional disclosure report. Returns one US Senate disclosure report from the filing_url found by the stock-disclosures search, passed as url. Supports annual reports, periodic transaction reports and due date extension notices. Output has filer, filing date, parts with their rows, and a transactions list. House PDFs and paper filings return a validation error.

Input Schema

NameRequiredDescriptionDefault
urlYesFiling URL, as returned by congress-stock-disclosures' filing_url field. Must be an efdsearch.senate.gov /search/view/annual/..., /search/view/ptr/..., or /search/view/extension-notice/regular/... URL.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/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, and it does disclose meaningful behavior: the expected output shape (filer, filing date, parts with rows, transactions list) and a concrete failure mode (House PDFs and paper filings produce a validation error). It omits auth/rate-limit context, but for a read-only filing fetch the disclosed error behavior is the key trait.

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?

Four short sentences, front-loaded with the purpose before the source, supported types, and output/error notes. Every sentence adds distinct information with no restatement or filler.

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 annotations and no output schema, the description must carry the behavioral load, and it covers purpose, URL provenance, supported report types, return shape, and failure conditions. It is nearly complete for a one-parameter fetch tool, though it says nothing about rate limits or volume.

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 single `url` param is already fully documented in the schema, including the same filing_url provenance and URL-form constraints. The description repeats this context rather than adding syntax beyond what the schema provides, 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 and resource ('Fetch and parse a congressional disclosure report') and pins down scope ('one US Senate disclosure report'). It explicitly differentiates itself from the sibling congress_stock_disclosures by naming that tool as the source of the URL, so an agent can place it in the workflow without opening either schema.

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?

It names the upstream tool (the stock-disclosures search's filing_url field) and states the exact URL shapes accepted, plus a clear when-not: House PDFs and paper filings return a validation error. It does not, however, name an alternative for the unsupported House case, so it stops short of full alternative routing.

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

Deploy Server

Other Tools