Skip to main content
Glama

ca-rate-filings

by ai.serff

Get Filing Regulatory Dossier

get_filing_dossier
Read-onlyIdempotent

Use this to see the full REGULATORY POSITION of a filing in one call — current CDI status, who is reviewing it, the entire objection history, filer contacts, and lineage to predecessor filings. NOT the tool if the question is about rating mechanics, base rates, factor tables, or actuarial numerics. For those, chain into get_filing_summary (actuarial narrative), search_actuarial_embeds (numerics), or search_filing_embeds (paragraph-level body).

Right questions this answers in one shot:

  • "Where does FARM-134879410 stand at CDI right now?" — status, pending/closed, live objections, who's on it

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

  • "Was this objected to? Approved? Withdrawn? Who reviewed it?" — the derived block answers at-a-glance

  • "Show me the objection thread + carrier lineage + references for this SERFF" — all sections inline

Composes get_filing_summary, get_filing_correspondence, get_filing_references, and get_filing_lineage in parallel for one SERFF id and returns the union along with a derived at-a-glance block. Each sub-fetch is independent — a missing summary or errored lineage still leaves the rest intact (each section carries a per-section error field on failure).

Wrong surface for:

  • Search — start with search_filings / search_summary_embeds / search_correspondence_embeds to find the SERFF, then dossier from there

  • Caseload / aggregate views — use list_email_workload for "which reviewer is on the most Pending filings"

Returns { serff, meta, derived, summary, correspondence, references, lineage }. The derived block carries {has_summary, correspondence_file_count, correspondence_chunk_count, has_objections, cdi_reviewer_emails, reference_count, lineage_depth} — enough for a client to render a status card without walking every sub-payload.

Input Schema

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

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds valuable behavioral detail beyond annotations: it reveals that the tool composes four sub-fetches in parallel, that failures are isolated per-section with an 'error' field, and that a derived at-a-glance block is included. This materially helps an agent predict partial-failure behavior and response structure.

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?

Although long, the description is tightly structured: bolded core purpose, bulleted example questions, a clearly marked 'Wrong surface for' section, and a compact return-shape line. Every sentence earns its place, and the most important guidance is front-loaded before alternatives and exclusions.

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 composite tool with one parameter and no output schema, the description is complete: it names the composed tools, the returned top-level fields, the derived block contents, failure isolation behavior, and exclusions. An agent has everything needed to decide when to call it and what to expect back.

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 fully documents 'serff' including format, validation regex, and error behavior. The description reinforces that the tool takes one SERFF id and composes over it, but does not need to add meaning — the baseline of 3 applies since the schema carries the parameter documentation burden.

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 opens with a specific verb and resource: 'see the full REGULATORY POSITION of a filing' and enumerates exactly what that includes (CDI status, reviewer, objection history, filer contacts, lineage). It also explicitly distinguishes itself from rating-mechanics tools by naming what it is NOT for, making sibling differentiation immediate.

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 gives explicit when-to-use ('Use this to see the full regulatory position...') and explicit when-not-to-use ('NOT the tool if the question is about rating mechanics... For those, chain into get_filing_summary...'). It further lists 'Wrong surface for' search and caseload scenarios and names the correct starting tools, leaving no ambiguity about routing.

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