Skip to main content
Glama

ca-rate-filings

by ai.serff

Get Regulatory Exchange — Objection Thread + Filer Docs

get_filing_correspondence
Read-onlyIdempotent

Use this to see the REGULATORY POSITION history of a filing — the whole CDI ↔ carrier dialogue plus filer contact info — in order. NOT for the filing's content, rates, or forms. Content questions live in get_filing_summary (actuarial narrative), get_filing_source_file_link (raw PDFs for human download), and search_filing_embeds (paragraph-level body search).

Right questions this answers:

  • "Show me the full objection thread on FARM-134879410" — every letter, in order

  • "Who filed this and who reviewed it at CDI"

  • "What did the carrier say in response to CDI's second objection"

  • "Give me the paper trail so I can audit how this filing progressed"

Fetches every chunk in correspondence_embeds for the given SERFF, grouped by source_file (one entry per attachment) and ordered by chunk_index within each file. Covers three attachment types:

  • correspondence_attachment_*.pdf — the objection thread (CDI questions + carrier responses + follow-ups)

  • supporting_document_attachment_*.pdf — actuarial memos, exhibits, transmittal letters (filer contact / authorship signals)

  • .pdf — SERFF's top-level cover page with filing-person contact block

Everything comes back as readable text so the caller can quote it verbatim to the user. Group by source_file prefix client-side if you only want, e.g., the objection thread (correspondence_attachment_*).

For a one-call summary that ALSO includes filing metadata, extracted summary, references, and lineage alongside the correspondence, use get_filing_dossier.

Right surface for:

  • "Show me the objection thread on this filing" — after a search or when the user hands you a SERFF id and asks what CDI said.

  • "Pull the carrier's full response to CDI's second-round questions" — you get everything, in order; extract the passage you need.

  • Auditing/review workflows where a regulator wants the full paper trail on one filing.

Right combination: pair with search_correspondence_embeds — that surface finds candidate filings semantically; this one pulls the whole thread once you've picked one worth reading end-to-end.

Coverage: not every filing has correspondence. Only filings that received at least one objection round from the DOI (or the carrier uploaded a proactive supplemental letter under the same correspondence_attachment_ prefix) will have chunks. A filing with no exchange returns { files: [], chunk_count: 0 } — not an error.

Returns { serff, files: [{ source_file, chunks: [{ chunk_index, text, emails, email_domains, page_date }] }], file_count, chunk_count }. Each chunk's text is capped at 2000 chars.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
serffYesCanonical SERFF id, shape PREFIX-IDENTIFIER (e.g. "ACEH-134881437"). Validated against /^[A-Z]{3,5}-[A-Z0-9]{7,15}$/; invalid values return an error envelope.

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true. The description goes far beyond these by disclosing the response structure, the 2000-char chunk cap, the behavior for filings without correspondence (returns empty structure, not an error), the grouping/ordering logic, and the three attachment types. This is comprehensive behavioral transparency that adds significant value over the annotations.

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?

The description is lengthy but well-structured with headings, bullet points, and examples. The core purpose and alternatives are front-loaded, and each section (examples, technical details, coverage notes, return shape) serves a distinct purpose. Some redundancy exists, such as the 'Right questions' list partially duplicating the opening statement, but overall it is efficiently organized for an agent to parse.

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 tool with this complexity (multiple attachment types, grouping, chunk caps, empty coverage, return shape), the description covers all necessary aspects: purpose, usage boundaries, technical behavior, coverage caveats, and alternatives. Even without an output schema, the return structure is fully spelled out with field names and types. Nothing an agent needs to call it correctly is missing.

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 fully documents the `serff` parameter (100% coverage), including its format, validation regex, and error handling for invalid values. The description does not add any additional semantic context for the parameter itself; it only mentions 'given SERFF' in passing. Since the schema carries the full burden, the baseline of 3 is appropriate.

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?

The description clearly states the tool's function: 'see the REGULATORY POSITION history of a filing — the whole CDI ↔ carrier dialogue plus filer contact info — in order.' It explicitly distinguishes itself from content-related tools by naming specific alternatives (get_filing_summary, get_filing_source_file_link, search_filing_embeds) and provides concrete example questions. This is a specific verb+resource+scope with strong sibling differentiation.

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?

The description explicitly says what the tool is NOT for and routes to alternatives ('NOT for the filing's content, rates, or forms. Content questions live in get_filing_summary...'). It also provides 'Right surface for' scenarios and a pairing recommendation with search_correspondence_embeds, plus a note about the more comprehensive get_filing_dossier. The usage guidance is thorough and actionable, leaving no ambiguity about when to use vs alternatives.

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

All ca-rate-filings toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation4/5

The get_filing_* family has distinct purposes, though get_filing_lineage and get_filing_references could be confused without the detailed descriptions. The search_* tools are clearly separated by embedding surface, and dossier/composite vs single-filing retrievals are explicitly differentiated.

Naming Consistency5/5

All tools follow a consistent verb_noun snake_case pattern with clear prefixes: get_filing_*, search_*, list_*, and mcp_*. No style mixing or vague generic verbs.

Tool Count4/5

At 16 tools, this sits at the upper edge of the ideal range. Each tool earns its place, though get_filing_dossier could have been a client-side composition of the other get_filing_* calls rather than a separate tool.

Completeness5/5

The domain (retrieving CA rate filings) is covered end to end: structured and semantic search across multiple granularities, filing summaries, correspondence threads, actuarial numerics, lineage, source file listing/download, and reviewer caseload. The read-only nature of the domain means no create/update operations are needed, and every retrieval path leads to a terminal artifact.

Resources