ca-rate-filings

Get Filing Lineage

get_filing_lineage

Read-onlyIdempotent

Returns the reconciled lineage chain for a SERFF id — leaf filing plus ordered predecessors back to the bureau root. Each chain entry includes the SERFF id, position (0 = leaf), role (leaf / predecessor), and a lite filing record (state, year, carrier name, product name, filing type, filing date).

Distinct from get_filing_references, which returns what the filing itself claims inside the PDF. Use this when you want the canonical chain (e.g. "what's the bureau root and prior versions for this Progressive auto programme?"); use get_filing_references when you want the carrier-stated lineage.

Walks back from any SERFF in a programme's chain — pass either the leaf or any predecessor and you get the same chain back. Returns { error: ... } if the SERFF id has not been resolved into any programme chain (the filing may be a non-rate-affecting type — Withdrawal / Correspondence — or simply not yet ingested).

Pair with search_filings using predecessor_prefix: search returns "filings that some programme adopted from bureau X"; lineage tells you, for any of those filings, the full chain it sits in.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`serff`	Yes	Canonical SERFF id, shape PREFIX-IDENTIFIER (e.g. "AAIC-134567890"). Either the leaf or a predecessor — the chain is returned regardless. 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?

The description adds behavioral context beyond annotations, such as walking back from any SERFF in a program's chain, returning an error if not resolved, and noting possible non-rate-affecting types. No contradiction with annotations (readOnlyHint, idempotentHint).

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?

The description is well-structured and front-loaded with the main purpose, followed by differentiation from siblings and additional usage details. Each sentence adds value without redundancy.

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?

The description covers the return structure (chain entries with SERFF id, position, role, lite filing record), error handling, and relationship to sibling tools. Given the single parameter and no output schema, it provides sufficient context for an AI agent.

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 coverage is 100% with a detailed parameter description including regex validation and error envelope behavior. The description does not add significant new meaning beyond the schema, so baseline 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 returns the reconciled lineage chain for a SERFF id, specifying the verb 'returns' and the resource. It explicitly distinguishes itself from the sibling get_filing_references by noting the difference between canonical chain and carrier-stated lineage.

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 provides explicit guidance on when to use this tool ('when you want the canonical chain') versus when to use get_filing_references. It also suggests pairing with search_filings using predecessor_prefix, and explains the error case for unresolved SERFF ids.

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 tools Inspect

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

Need Help?