Skip to main content
Glama
PowerLaw-Technology

ferc-elibrary-mcp

search_filings

Search public FERC eLibrary filings by keyword, docket number, accession number, or document type, and apply date filters to retrieve relevant records.

Instructions

Search public FERC eLibrary filings. Public documents only.

Use for keyword/term search, docket prefix (CP, ER11-4046), accession numbers, or document types such as Order/Opinion, Comments/Protest, or Application/Petition/Request.

Date defaulting: when docket or accession_number is supplied, no date filter is applied and the whole proceeding is searched. For an open-ended query with no dates, the last 60 days is used to keep the result set manageable. Every response reports date_range_applied, date_range_source (explicit/default_60_day/none), and results_may_be_date_limited, so check those before treating total_hits as a complete count.

date_field selects which date start_date and end_date filter on. Use "issued" when computing deadlines: FPA 313(a) rehearing and most Commission-set comment and compliance clocks run from issuance, not from the filed date, and the two differ. Orders are generally best searched by issuance.

match controls how a multi-word query is interpreted. "phrase" (default) requires the exact phrase and is what you want when looking for a named agreement or document. "all" requires every term anywhere. "any" is FERC's loose term matching, which returns high volume and low precision.

search_in controls where the query is matched. "both" (default) covers descriptions and full document text. "description" is far more precise because it matches the filing title rather than any passing mention deep in an attachment. Use it when a phrase search still returns too much noise.

You may also pass eLibrary syntax directly (quotes, AND, OR, NOT, NEAR); it is forwarded unchanged.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo
limitNo
matchNophrase
queryNo
docketNo
categoryNo
end_dateNo
industryNo
search_inNoboth
date_fieldNofiled
start_dateNo
document_typeNo
accession_numberNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Install Server

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full disclosure burden and meets it well. It reveals the default 60-day window for open-ended queries, the no-date-filter behavior when docket or accession_number is supplied, and the presence of response flags like date_range_applied and results_may_be_date_limited. It also discloses nuanced behaviors around date_field and match modes that an agent would otherwise have to discover by trial.

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

Conciseness4/5

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

Well-structured with a clear opening and topic-focused paragraphs, each sentence adds useful information. The opening repeats 'public' twice ('public FERC eLibrary filings' and 'Public documents only'), which is minor redundancy; otherwise it is appropriately dense for a 13-parameter search tool.

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 complex search tool with no annotations, this description is unusually complete: it covers search scope, date defaults, parameter behavior, and response caveats. An output schema exists to define the return shape, so the description provides enough context for correct invocation without missing essential operational details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does. It explains docket, accession_number, date_field, match, search_in, and document_type with examples and usage guidance. Only page, limit, category, and industry are not directly addressed, but the most consequential parameters are richly specified.

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: 'Search public FERC eLibrary filings.' It also scopes the tool with 'Public documents only' and lists concrete supported query keys (keywords, docket prefix, accession numbers, document types), making it clearly distinguishable from siblings like get_filing or list_files.

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?

Gives clear context on how to search: which fields to use, date defaulting behavior, and trade-offs between match and search_in modes. It stops short of explicitly saying when not to use this tool versus a sibling like get_filing, so it lacks explicit when-not/alternatives guidance.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/PowerLaw-Technology/ferc-elibrary-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server