Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-chainladder Run chain ladder on my paid-loss triangle"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Actuarial chain-ladder reserving for Claude. A Model Context Protocol server that hands Claude the tools to compute IBNR, project ultimates, run Mack (1993) stochastic error estimates, check Mack (1994) model assumptions, and parse loss triangles from CSV — all from a natural- language conversation.
Calculation only — not actuarial advice. This is a mechanical chain-ladder calculator. Selection of data, factors, tails, and exclusions, and the interpretation of stochastic error measures, require professional actuarial judgement.
Eight tools, exposed over MCP. Claude picks the right one when you ask a question; you don't have to call them by name.
Tool | When Claude reaches for it |
| "What's the IBNR on this triangle?" — the workhorse |
| "What does the full projected triangle look like?" |
| "What's the uncertainty on the total reserve?" |
| "Are there outliers or trend issues?" |
| "Run the chain ladder on this CSV file" |
| "Show me the incremental development pattern" |
| "Cumulate these incremental values" |
| "Show me a working example" — quick demo |
All numerical conventions match the Mack 1993 and Mack 1994 papers; results are stable to ~1e-12 against hand calculation on the textbook 10×10 triangle.
Related MCP server: JACTUS MCP Server
pipx install mcp-chainladder
# or, to run on demand without installing:
uvx mcp-chainladderPython 3.10 or newer; no other runtime dependencies beyond the official MCP SDK.
Edit ~/Library/Application Support/Claude/claude_desktop_config.json
(macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"chainladder": {
"command": "uvx",
"args": ["mcp-chainladder"]
}
}
}Quit and reopen Claude Desktop. The triangle tools appear under the 🔌 icon in any conversation.
For Cursor / Cline / Continue / Zed — same mcpServers block, each app
has its own config file location (their docs walk you through it).
Me: I have a paid-loss triangle at ~/Desktop/motor_2026Q1.csv.
Run the chain ladder and tell me the IBNR.
Claude: [calls parse_csv_triangle, then compute_chain_ladder]
Loaded a 10×10 cumulative triangle. Using volume-weighted
factors:
• Total paid to date: 49,458,000 USD
• Total ultimate: 65,883,400 USD
• Total IBNR: 16,425,400 USD
Selected factors trend from 1.879 at the front of the
triangle down to 1.002 at the tail.Me: Same triangle — any reason not to trust the projection?
Claude: [calls mack_diagnostics]
Three flags worth a look:
• Inflation trend: slope 0.053, p ≈ 1e-12 — STRONG evidence
link ratios are drifting upward across accident years.
This violates Mack's homogeneity assumption; consider
weighting recent years more.
• Calendar-year: Z = 0.0, p = 1.0 — no diagonal effect.
• Independence: Z = -0.35, p = 0.73 — no obvious dependence
across development columns.
• Outliers: 0 cells exceed |2σ|.
The inflation finding is the one to act on.Me: Drop the link ratio at AY 3, dev period 2→3. What changes?
Claude: [calls compute_chain_ladder with excluded=[[2, 1]]]
Excluding (AY 3, 2→3):
• Volume factor at 2→3 moves from 1.331 to 1.328
• Total IBNR moves from 16,425 to 16,389 (−36)
• Mack SE total moves from ±354.6 to ±348.2
Net: small enough to be a "robustness check passes" rather
than a finding.Each tool returns a JSON object (or a 2-D list, in the case of
project_triangle/to_incremental/to_cumulative). Claude reads the
descriptions and types directly from the server — you don't need to
memorise the shapes — but here's the cheat sheet.
compute_chain_ladder(triangle, selected_factors?, tail?, excluded?)End-to-end chain ladder.
Field returned | Meaning |
| All-year volume-weighted age-to-age factor for transition j→j+1 |
| Unweighted average of individual link ratios |
| The factor set actually used to project (defaults to volume) |
| Per-row link ratio |
| Cumulative dev factor to ultimate; |
| Most recent observed value per AY |
| Projected ultimate per AY |
| Ultimate − Latest per AY |
| Sums of the three above |
| Triangle dimensions |
mack_stochastic(triangle, selected_factors, excluded?)Mack (1993) distribution-free standard errors. Returns σ̂²_j per dev period (tail-rule backfilled when only one observation), SE & CV per row, and SE_total / CV_total including cross-row covariance per eq. 5.15.
mack_diagnostics(triangle, selected_factors, excluded?, outlier_threshold?)Returns standardised residuals, outliers (|r| > threshold, default
2.0), the calendar-year sign test, Spearman independence test across
adjacent dev columns, and the inflation slope of mean log-link-ratio
against accident-year index.
p-value bands to translate to plain English:
p < 0.005 → strong evidence
p < 0.05 → significant
p < 0.10 → borderline
p ≥ 0.10 → no evidenceparse_csv_triangle(path)Reads a CSV from disk, treats blank / NA / NaN / N/A / − cells as unobserved, strips embedded thousand-separator commas, and skips header / metadata rows. Returns the triangle + dimensions + the absolute path read (useful for the assistant to confirm what it loaded).
project_triangle(triangle, selected_factors)Fills the lower-right of the triangle with chain-ladder projections.
Returns a fully-rectangular list[list[float]] (no nulls). NaN where
a row has no observation to project forward from.
to_incremental(cumulative) / to_cumulative(incremental)Two conversions. Unobserved cells stay unobserved; the inverse on observed cells is exact.
sample_triangle()Returns the textbook 10×10 cumulative paid triangle. Use as a
self-check: pass it to compute_chain_ladder and you should get
Paid 49,458 / Ultimate 65,883 / IBNR 16,425.
[
# AY 1 — fully developed
[1000, 1855, 2423, 2988, 3335, 3483, 3552, 3603, 3624, 3631],
# AY 2 — observed through dev 9
[1113, 2103, 2774, 3422, 3844, 4010, 4090, 4148, 4172, None],
# …
# AY 10 — only the first observation
[2640, None, None, None, None, None, None, None, None, None]
]Outer index = accident year, oldest first
Inner index = development period, 0 = first age
Use None (or JSON null) for unobserved cells
All rows must be the same length — pad with trailing null
pipx install --editable mcp-chainladder
pytest -qTests pin every public tool against the textbook triangle's well-known parity values to ~1e-9.
<< UNDER REVIEW - COMING SOON >>
The free tier covers all 8 tools listed above. Pro unlocks
additional methods + bulk workflows, gated by a local license file
at ~/.chainladder/license (or wherever $CHAINLADDER_LICENSE_FILE
points).
Pro licenses are currently for internal and testing purposes only — not open to the public. No purchase channel is available at this time. The Pro tools are listed below for reference and will continue to return
pro_license_requiredfor external users.
Pro tool | What it does |
| Inspect current license state (free to call) |
| Mack tests with verdict labels + plain-English summaries + recommended actions |
| Drop each link ratio one-at-a-time and rank by IBNR impact |
| Fit exponential + inverse-power tail models, recommend best fit |
| BF reserving method with side-by-side CL comparison |
| Run CL + BF in one call, report deltas + largest divergence |
| Full 5-page actuarial PDF — cover / triangle / factors / results / 3D loss surface |
| Fold the chain ladder over a directory of CSV triangles |
| Additional reserving methods, all returning side-by-side comparisons |
{
"product": "mcp-chainladder-pro",
"owner": "alice@example.com",
"expires": null,
"key": "CL-PRO-1A2B3C4D",
"signature": "…"
}Drop it at ~/.chainladder/license (the file's directory must exist;
the server doesn't create it). Pro tools immediately respond as
unlocked the next time Claude calls them.
When the license is missing or expired, every Pro tool returns
{"error": "pro_license_required", "status": {...}} instead of
computing — Claude reads the status and points you to the upgrade
URL. The free-tier tools always work regardless of license state.
MIT. See LICENSE.
Bornhuetter-Ferguson (1972) reserving method. Pro tier.
Combines the chain-ladder development pattern with an externally- provided a-priori ultimate per accident year, giving a result that is far less sensitive to noisy late development than pure chain ladder. The canonical "second method" for benchmarking reserves — when chain-ladder and BF agree, you can publish with confidence; when they diverge, the divergence is the finding.
Args:
triangle: Cumulative loss triangle, same shape as
compute_chain_ladder.
a_priori_ultimates: Expected ultimate per accident-year row,
usually derived from premium × expected loss ratio or
a plan figure. Must have length n_acc.
selected_factors: Override factor set; defaults to volume-
weighted (same default as chain ladder).
tail: Multiplicative tail factor. Default 1.0.
excluded: Outlier exclusions, same shape as in
compute_chain_ladder.
Returns either:
- On success: {a_priori_ultimates, used_up_proportion, bf_ultimates, bf_ibnr, cl_ultimates, cl_ibnr, total_bf_ultimate, total_bf_ibnr, total_cl_ultimate, total_cl_ibnr} — note the chain-ladder values are returned
alongside so the user can see the two methods side-by-side.
- On license failure: {error, status} with status giving the
upgrade URL and reason. Free-tier callers get this and can
still see the API shape; no compute happens.
| Name | Required | Description | Default |
|---|---|---|---|
| triangle | Yes | ||
| a_priori_ultimates | Yes | ||
| selected_factors | No | ||
| tail | No | ||
| excluded | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it performs the BF method, returns both BF and chain-ladder results, and handles license failures by returning an error with upgrade URL. No contradictory or missing details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, args, and returns sections. It is slightly verbose but every sentence adds value; could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, output schema, license tier), the description is thorough: it explains input formats, defaults, return fields, and error behavior. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden. It provides detailed explanations for all 5 parameters, including defaults (tail=1.0, selected_factors null) and relationships, adding significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies it as the Bornhuetter-Ferguson reserving method, explains its purpose (combines chain-ladder development with a priori ultimate), and distinguishes it from siblings like compute_chain_ladder by positioning it as a benchmarking method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use it (canonical second method for benchmarking reserves) and how it relates to chain ladder, but does not explicitly state when not to use it or mention alternative tools by name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run chain ladder + Bornhuetter-Ferguson on the same triangle and return a side-by-side comparison. Pro tier.
The canonical "second opinion" — when both methods agree, the reserve is defensible; when they diverge, the divergence is the finding. Reports total deltas plus the single AY where the two methods disagree most.
Args:
triangle: As in compute_chain_ladder.
a_priori_ultimates: One expected ultimate per AY for the BF
method.
selected_factors, tail, excluded: As in compute_chain_ladder.
Returns either:
- On success: {chain_ladder, bornhuetter_ferguson, diffs_by_ay, total_diff_ultimate, total_diff_ibnr, largest_divergence}.
- On license failure: {error, status}.
| Name | Required | Description | Default |
|---|---|---|---|
| triangle | Yes | ||
| a_priori_ultimates | Yes | ||
| selected_factors | No | ||
| tail | No | ||
| excluded | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that results include total deltas and the single AY with largest divergence, and mentions possible license failure. It does not detail error handling for invalid inputs, but overall provides good behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and usage guidance, followed by parameter list and return values. It is well-structured but slightly lengthy with the detailed return fields. Good balance of completeness and conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with 2 required and an output schema present, the description covers purpose, usage, parameter references, and return fields including error case. Reliance on cross-reference for parameter details is a minor gap, but overall contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. The description references 'As in compute_chain_ladder' for triangle, selected_factors, tail, excluded, and explains a_priori_ultimates. This adds meaning but relies on cross-reference, which is minimal adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs chain ladder and Bornhuetter-Ferguson on the same triangle and returns a side-by-side comparison. It distinguishes itself from sibling tools that compute individual methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'The canonical second opinion — when both methods agree, the reserve is defensible; when they diverge, the divergence is the finding.' It also notes the Pro tier, implying licensing requirements. However, it does not explicitly state when not to use this tool or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a full chain-ladder reserving calculation on a cumulative loss triangle. This is the workhorse tool — call it whenever the user asks "what's the IBNR?", "what does the chain ladder say?", or hands you a triangle and asks for projections.
Args:
triangle: Cumulative loss triangle as a list of lists. Outer index
is the accident-year row (oldest first). Inner index is the
development period (0 = first age). Cells are numbers or null;
null means unobserved (typical lower-right corner of a real
triangle). All rows should be the same length — pad with
trailing nulls if needed.
selected_factors: Optional list of user-chosen age-to-age factors,
one per development-period transition (length = n_dev - 1).
When omitted, the volume-weighted factors derived from the
triangle are used as the selected set.
tail: Multiplicative tail factor applied beyond the last
development period. Default 1.0 (no tail).
excluded: List of [row_i, dev_j] pairs identifying individual
link ratios to drop from the volume and simple averages. Use
this for outlier handling — typically after consulting
mack_diagnostics to find suspect cells.
Returns:
A dictionary containing:
- volume_factors: list[float] — volume-weighted age-to-age
- simple_factors: list[float] — simple average of link ratios
- selected_factors: list[float] — the set actually used
- individual_factors: list[list[float | None]] — per-row link
ratios C[i, j+1] / C[i, j]; null where the pair is unobserved
- cdf: list[float] — cumulative dev factors to ultimate; last
element is tail
- latest_diagonal: list[float] — most recent observed value per
accident row
- ultimates: list[float] — projected ultimate per accident row
- ibnr: list[float] — Ultimate − Latest, per accident row
- total_latest, total_ultimate, total_ibnr: float scalars
- n_acc, n_dev: int — triangle dimensions for convenience
| Name | Required | Description | Default |
|---|---|---|---|
| triangle | Yes | ||
| selected_factors | No | ||
| tail | No | ||
| excluded | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the responsibility of disclosing behavior. It thoroughly explains the computation, parameters, and output structure, including handling of nulls and the effect of optional arguments. This provides complete transparency for a mathematical tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief intro followed by clearly labeled Args and Returns sections. While it is detailed, every sentence provides necessary information. It could be slightly more concise, but the organization makes it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of chain-ladder reserving and the presence of an output schema, the description is remarkably complete. It covers all inputs, default behaviors, and each field of the return dictionary. No gaps are evident for typical usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage (no parameter descriptions in the schema). The tool's description compensates fully with detailed explanations of each parameter (triangle format, selected_factors defaults, tail default, excluded format). This adds significant value beyond the schema's types and titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run a full chain-ladder reserving calculation on a cumulative loss triangle' and gives explicit usage cues like 'call it whenever the user asks "what's the IBNR?".' This distinguishes the tool from siblings such as bornhuetter_ferguson and mack_diagnostics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool ('when the user asks... or hands you a triangle and asks for projections') and labels it as the 'workhorse tool.' However, it does not explicitly mention when not to use it or contrast it with alternatives, which would improve the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Mack assumption diagnostics + label each result with a plain- English verdict and a recommended action. Pro tier.
Free-tier mack_diagnostics returns raw Z-scores and p-values; this
Pro variant adds:
• verdict band ("strong evidence" / "significant" / "borderline" / "no evidence") for each test, using the standard p-value cutoffs • a one-paragraph summary written so Claude can read it back to the user without further interpretation • a specific recommended action for each finding ("try BF", "weight recent years only", "investigate cells X, Y, Z", …) • an overall verdict pulling the three tests + outlier scan together into a single sentence
Use this when the user asks "is the chain ladder OK?", "should I publish this?", or "what does the model tell me about itself?".
Args:
triangle: As in compute_chain_ladder.
selected_factors: Length-(n_dev - 1) factor set used for the
point estimate.
excluded: Outlier exclusions to honour.
outlier_threshold: Absolute residual threshold for flagging
cells (default 2.0).
Returns either:
- On success: {calendar_year, independence, inflation, outliers, overall} — each test object carries stat,
p_value, verdict, summary, recommendation. The
outliers object also reports count, severity
(clean / mild / moderate / severe), and a list of flagged
cells.
- On license failure: {error: "pro_license_required", status: {...}}.
| Name | Required | Description | Default |
|---|---|---|---|
| triangle | Yes | ||
| selected_factors | Yes | ||
| excluded | No | ||
| outlier_threshold | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses that the tool returns either a success object with detailed test results or an error object for license failure. It does not mention side effects or permissions, but the 'Pro tier' designation and license error imply access control. The description is thorough but stops short of stating whether the tool is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear flow: core purpose, feature list, usage cues, parameter list, return value structure. It is concise for the amount of information conveyed, though the feature list could be slightly compressed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and an output schema that presumably captures return structure, the description covers the essential aspects: what the tool does, when to use it, return value on success and failure, and high-level parameter meanings. It lacks detailed parameter formats but compensates with example usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It lists the four parameters but provides minimal detail: 'triangle: As in compute_chain_ladder' is vague, and 'excluded: Outlier exclusions to honour' lacks specificity. The defaults are mentioned only for outlier_threshold. Given the lack of schema descriptions, the parameter explanations are insufficient to fully understand input formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes Mack assumption diagnostics and labels results with verdicts and recommendations. It distinguishes itself from the free-tier 'mack_diagnostics' by listing four specific added capabilities (verdict band, summary, recommendation, overall verdict).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage cues: 'Use this when the user asks "is the chain ladder OK?", "should I publish this?", or "what does the model tell me about itself?".' Also contrasts with free-tier 'mack_diagnostics' to guide when to use this Pro version.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mack (1994) assumption diagnostics — three statistical tests plus standardised-residual outlier detection. Use when the user asks "does the chain ladder look OK?", "are there any outliers?", or "should I be worried about [calendar-year / inflation / dependence] effects?".
Args:
triangle: As in compute_chain_ladder.
selected_factors: Length-(n_dev - 1) factor set.
excluded: Outlier exclusions to honour.
outlier_threshold: Absolute standardised-residual threshold for
flagging an outlier. Default 2.0 (the Tk app's default).
Returns:
- standardised_residuals: list[list[float | null]] — per-cell
residual r[i,j] = (C[i,j+1] − f_j·C[i,j]) / (σ_j·√C[i,j]);
null where the cell is excluded or the pair is unobserved
- outliers: list of {row: int, dev: int, residual: float} —
cells with |residual| > outlier_threshold
- calendar_year: {z: float, p_two_sided: float} — Tarbell
sign test for calendar-year effects (large |z| ⇒ suspect)
- independence: {z: float, p_two_sided: float} — Spearman
rank-correlation between adjacent development columns (large
|z| ⇒ link ratios are not independent)
- inflation: {slope: float, p_value: float} — OLS slope of
mean(ln link-ratio) on accident-year index (non-zero ⇒
accident-year trend in link ratios)
Verdict guidance for translating p-values to plain English: p < 0.005 → "strong evidence"; p < 0.05 → "significant"; p < 0.10 → "borderline"; p ≥ 0.10 → "no evidence".
| Name | Required | Description | Default |
|---|---|---|---|
| triangle | Yes | ||
| selected_factors | Yes | ||
| excluded | No | ||
| outlier_threshold | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the three statistical tests performed, outlier detection method, and return structure including formula for residuals. No side effects mentioned, but appropriate for a read-only diagnostic tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with Args, Returns, and Verdict guidance sections. Front-loaded with purpose. Slightly lengthy but justified by the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides complete information including return values with types and interpretation guidance. Given the presence of an output schema (described in text), the description covers all necessary context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds detailed descriptions for all 4 parameters beyond the schema (which has 0% coverage). Explains each parameter's role, including defaults and relationships (e.g., selected_factors length, outlier_threshold default).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it performs Mack (1994) assumption diagnostics including three tests and outlier detection, and gives example use cases. Distinguishes itself from siblings like compute_chain_ladder and interpret_diagnostics by focusing on statistical tests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage scenarios: when user asks about chain ladder assumptions, outliers, or specific effects. Implicitly ties to compute_chain_ladder but lacks explicit when-not-to-use or alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mack (1993) stochastic chain-ladder error estimation. Returns distribution-free standard errors and coefficients of variation per accident row plus the totals — the canonical sensitivity check for a deterministic chain-ladder result.
Use this when the user asks about uncertainty, reserve risk, or
confidence intervals. Pair it with compute_chain_ladder (use the
same selected_factors for consistency).
Args:
triangle: As in compute_chain_ladder.
selected_factors: The factors used for the point-estimate
projection. Length = n_dev - 1.
excluded: Outlier exclusions to honour, same shape as in
compute_chain_ladder.
Returns:
- sigma2: list[float] — σ̂_j² per development period; backfilled
via Mack's tail rule when only one observation is available
- se_per_row: list[float] — standard error of each ultimate
- cv_per_row: list[float] — coefficient of variation (SE /
Ultimate) per accident row
- se_total: float — SE of the sum of all ultimates (includes
cross-row covariance per Mack eq. 5.15)
- cv_total: float — CV of the total ultimate
| Name | Required | Description | Default |
|---|---|---|---|
| triangle | Yes | ||
| selected_factors | Yes | ||
| excluded | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the output in detail, mentions backfilling via Mack's tail rule and cross-row covariance, but does not explicitly state side effects or authorization needs. Given the computational nature, transparency is strong though not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a clear purpose paragraph, usage paragraph, and structured Args/Returns sections. Every sentence adds value, concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all 3 parameters, explains all 5 return fields with types and interpretations, and references sibling tool for consistency. Given the output schema exists, the description is complete for an experienced user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds comprehensive parameter details: triangle references compute_chain_ladder, selected_factors includes length constraint, and excluded explains shape and nullability. This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs stochastic chain-ladder error estimation, returning standard errors and coefficients of variation. It distinguishes from sibling tools like compute_chain_ladder (point estimate) and mack_diagnostics by focusing on uncertainty quantification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use when the user asks about 'uncertainty, reserve risk, or confidence intervals' and recommends pairing with compute_chain_ladder using the same selected_factors for consistency. Provides clear context for when to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a CSV file from disk into a cumulative loss triangle.
Reads the file, treats empty cells and the tokens "NA", "N/A", "NaN", "-" as unobserved, strips embedded commas (thousand separators), and drops any leading row whose first cell is non-numeric but whose remaining cells are mostly numeric (e.g. a "Dev 1, Dev 2, …" header). Auto-pads jagged rows to a rectangle with nulls.
Use this when the user gives you a CSV file path and wants to run the chain ladder on it.
Args:
path: Absolute or ~-relative path to the CSV file. Must be
readable by the server process.
Returns:
- triangle: list[list[float | null]] — parsed cells, ready to
pass to compute_chain_ladder
- n_acc: int — number of accident-year rows
- n_dev: int — number of development periods (max row length)
- source: str — absolute path actually read
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses specific behaviors: handling of empty cells and tokens, stripping commas, dropping header rows, padding jagged rows, and path requirements. It lacks error handling or performance details but is still informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with separate sections (Args, Returns) and front-loaded with the main purpose. It is somewhat lengthy but each sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no nested objects) and presence of an output schema (implied by 'Has output schema: true'), the description fully covers the tool's behavior, return values, and use case, leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'path' has no description in the input schema (coverage 0%). The tool description adds critical details: path must be absolute or ~-relative and readable by the server process, providing meaning beyond the schema type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Parse'), resource ('CSV file'), and outcome ('cumulative loss triangle'). It distinguishes itself from sibling tools that perform different operations (e.g., compute_chain_ladder, project_triangle).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a usage condition: 'Use this when the user gives you a CSV file path and wants to run the chain ladder on it.' While it does not list exclusions, the guidance is clear and relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill the lower-right (unobserved) cells of a cumulative triangle using the supplied age-to-age factors.
Args:
triangle: As in compute_chain_ladder.
selected_factors: One factor per development-period transition.
Length must be n_dev - 1.
Returns a dict with:
- triangle: 2-D list of floats, same shape as the input, with
unobserved cells filled in by chain-ladder projection. Rows
with no observation contain nan for the projected cells.
- disclaimer: standard actuarial-use disclaimer.
| Name | Required | Description | Default |
|---|---|---|---|
| triangle | Yes | ||
| selected_factors | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses key behaviors: fills only unobserved cells, nan for rows with no observation, returns a dict with disclaimer. However, it does not mention error handling (e.g., factor length mismatch) or side effects, but overall is transparent for a projection operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (a few sentences), uses clear section headers (Args, Returns), and front-loads the main purpose. Every sentence provides necessary information without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (projection using chain-ladder), the description covers inputs, constraints, output format, and a notable behavioral detail (nan for no-observation rows). It references an auxiliary tool for triangle format, which is acceptable. Minor gap: no explanation of the 'disclaimer' purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds significant meaning: triangle is 'as in compute_chain_ladder' (context), selected_factors has a length constraint and description of 'one factor per development-period transition'. This goes beyond the schema's mere names and types, though the triangle format could be more explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Fill the lower-right (unobserved) cells of a cumulative triangle using the supplied age-to-age factors.' It uses a specific verb ('Fill') and resource ('cells of a cumulative triangle'), and distinguishes itself from sibling tools like compute_chain_ladder by focusing on projection with precomputed factors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when age-to-age factors are already supplied (e.g., from compute_chain_ladder) but does not explicitly state when to use this tool versus alternatives. It lacks 'when-to-use' or 'when-not-to-use' guidance, leaving the agent to infer context from the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect the current Pro-tier license state. Returns whether Pro tools are unlocked, the registered owner, an expiry date if any, and a human-readable message that Claude can relay to the user. Free to call regardless of license state.
Returns:
- active: bool — whether the license is currently valid
- owner: str | null — email associated with the license
- expires: int | null — unix-epoch seconds, null = perpetual
- message: str — plain-English status (great for Claude to
read back to the user)
- upgrade_url: str — where to buy / renew
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers behavior: it states it is non-destructive, free to call, and explains each returned field in detail, including the role of the 'message' for Claude to relay.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose, then a bulleted list for returns. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (0 params), and the description fully explains what it does, when to call it, and what the output contains. No gaps remain given the low complexity and presence of output schema (documented in description).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description does not need to add meaning beyond the schema. The baseline for 0 params is 4, but the description excels by also detailing the output semantics, which is a bonus.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it inspects the Pro-tier license state and lists the exact return fields. It is distinct from all sibling tools, which are focused on insurance reserving methods, leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It indicates the tool is 'free to call regardless of license state,' which advises that it is safe to use anytime. No explicit when-not-to-use is needed due to the tool's simple nature and distinct purpose from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the classic textbook 10×10 cumulative-paid triangle
(Friedland-style). Useful for demos, examples, and verifying the
server is working — feed it to compute_chain_ladder to get the
well-known parity values (Paid 49,458 / Ultimate 65,883 /
IBNR 16,425 / Mack SE ±354.61).
Returns:
- triangle: the 10×10 list with the lower-right as null
- n_acc: 10
- n_dev: 10
- expected_totals: well-known parity values for cross-checking
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return structure (triangle with lower-right null, n_acc=10, n_dev=10, expected_totals) and mentions it's for parity checking. Since no annotations exist, it carries full burden and adequately describes behavior without side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a front-loaded main purpose, followed by structured return fields. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's purpose, output structure, and context (sample data for demos). With no parameters and an output schema available, it provides sufficient information for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so baseline is 4. The description doesn't need to add parameter meaning, and it doesn't attempt to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a 'classic textbook 10×10 cumulative-paid triangle (Friedland-style)' and mentions use cases like demos, examples, and server verification. It distinguishes from sibling tools by being a sample dataset, while siblings like parse_csv_triangle handle real data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool (demos, examples, verifying server is working) but doesn't explicitly mention when not to use it or suggest alternatives. However, the context of being a sample triangle implies it's not for real analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drop each observable link ratio one at a time, rerun the chain ladder, and rank the link ratios by their impact on total IBNR. Pro tier.
The fastest way to find the few observations that are actually
driving the projection. Use after mack_diagnostics flags outliers
— these are the cells to investigate first.
Args:
triangle: As in compute_chain_ladder.
selected_factors: Override factor set; defaults to volume-
weighted.
tail: Multiplicative tail factor.
excluded: Existing exclusions; the analysis honours these and
tests one additional cell at a time.
top_n: Cap on the number of "most influential" cells returned.
Default 10. Set higher for larger triangles.
Returns either:
- On success: {baseline_ibnr, n_tested, top_influential[], summary} — each top_influential entry has row, dev,
ratio, ibnr_with_excluded, ibnr_delta, ibnr_delta_pct.
- On license failure: {error, status}.
| Name | Required | Description | Default |
|---|---|---|---|
| triangle | Yes | ||
| selected_factors | No | ||
| tail | No | ||
| excluded | No | ||
| top_n | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the iterative process, ranking, and return types (including license failure). However, it doesn't mention side effects, performance implications, or the 'Pro tier' licensing details beyond a hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with separate sections for behavior, usage, args, and returns. It is concise yet informative, with no unnecessary fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the actuarial complexity and presence of output schema, the description covers purpose, usage, parameters, and return values (including error case). It is fairly complete, though could add more on prerequisites or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an Args section explaining each parameter with context (e.g., triangle 'as in compute_chain_ladder', excluded 'honours existing exclusions'). This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: dropping each link ratio, rerunning chain ladder, and ranking impact on IBNR. It provides specific verb and resource, with context about 'Pro tier' and use after mack_diagnostics, though it doesn't explicitly differentiate from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use after mack_diagnostics flags outliers — these are the cells to investigate first.' This gives clear when-to-use context, but lacks explicit when-not-to-use or alternatives beyond the implied order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fit parametric tail models to the late development factors and extrapolate forward. Pro tier.
Fits two candidate models — exponential decay
(ln(f_j - 1) = a + b·j) and inverse-power
(ln(f_j - 1) = a + b·ln(j+1)) — picks the better R², and
returns the implied tail factor for plugging back into
compute_chain_ladder(tail=…).
Use this when the triangle obviously hasn't reached ultimate by the last observed development period — i.e., the last selected factor is still meaningfully above 1.
Args: selected_factors: The factor set you want to extrapolate from. n_extra: How many extra development periods to project. Default 6 (covers most P&C lines).
Returns either:
- On success: {fits[], recommended, summary} — each fits
entry has model, parameters, r_squared,
extrapolated[], tail_factor.
- On license failure: {error, status}.
| Name | Required | Description | Default |
|---|---|---|---|
| selected_factors | Yes | ||
| n_extra | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the fitting process (two models, R² selection), return types (success or license error), and mentions the 'Pro tier' license. It is transparent about the computation but could add more detail on side effects (none) or prerequisites beyond license.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a header, explanation, usage guidance, parameter descriptions, and return format. It is concise with no wasted words, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's complexity (model fitting, multiple return paths, license dependency), the description covers all essential aspects: what it does, when to use, parameters, return structure, and error handling. The presence of an output schema further completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description provides clear explanations for both parameters: selected_factors as 'the factor set to extrapolate from' and n_extra with default 6 and context 'covers most P&C lines'. This adds significant meaning beyond the schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fits parametric tail models to late development factors and extrapolates forward, specifically for chain ladder tail factor. It distinguishes itself by mentioning plugging into compute_chain_ladder, a sibling tool, and specifying the two models used. The purpose is unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: when the triangle has not reached ultimate and the last factor is above 1. It also links to compute_chain_ladder for integration. However, it does not explicitly mention when not to use it or list alternative tools, though no direct alternative exists among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert an incremental triangle to cumulative (running sum per
row). Unobserved cells propagate as null. Inverse of
to_incremental on observed cells.
Args: incremental: Incremental triangle.
Returns dict with triangle (cumulative, same shape) and the
standard disclaimer.
| Name | Required | Description | Default |
|---|---|---|---|
| incremental | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that unobserved cells propagate as null and the relationship to to_incremental, but does not cover edge cases, permissions, or side effects. The description is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with purpose, and uses a clear Args/Returns structure. Every sentence serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 parameter, transformation, output schema present), the description covers input, behavior, null propagation, inverse relationship, and output format. The 'standard disclaimer' reference is vague but acceptable as a convention. Nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'incremental' is described as 'Incremental triangle' with 0% schema description coverage. While this adds semantic context beyond the raw schema (which only gives type), it lacks detail on shape, constraints, or examples. The description adds some value but is basic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it converts an incremental triangle to cumulative via running sum per row. It differentiates itself from the sibling to_incremental by explicitly naming it as the inverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states it is the inverse of to_incremental, providing clear guidance on when to use this tool versus its sibling. This is strong usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a cumulative triangle to incremental (per-period) values.
inc[i, 0] = cum[i, 0]
inc[i, j>0] = cum[i, j] - cum[i, j-1] (when both observed)
Unobserved cells stay unobserved.
Args: cumulative: Cumulative triangle, possibly with unobserved cells.
Returns dict with triangle (incremental, same shape) and the
standard disclaimer.
| Name | Required | Description | Default |
|---|---|---|---|
| cumulative | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that unobserved cells stay unobserved, provides the exact formula, and mentions the return value structure (dict with 'triangle' and disclaimer). This is good transparency for a transformation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using formulas and clear statements. It is front-loaded with the purpose, then provides the formula and a note about unobserved cells. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description sufficiently explains the return value. The tool is simple, and all necessary information (input format, transformation logic, treatment of nulls) is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning by describing the parameter as 'Cumulative triangle, possibly with unobserved cells.' This goes beyond the schema's type definition and helps the agent understand the expected input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Convert a cumulative triangle to incremental (per-period) values', providing a specific verb and resource. The sibling tool 'to_cumulative' does the opposite, so it distinguishes itself effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the mathematical transformation but does not explicitly state when to use this tool vs. alternatives like 'to_cumulative'. Implicitly, it's for converting cumulative to incremental, but no when-not-to or contextual guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.2.3bornhuetter_fergusoncompare_methodscompute_chain_ladderinterpret_diagnosticsmack_diagnosticsmack_stochasticparse_csv_trianglepro_license_statusproject_trianglesample_trianglesensitivity_analysistail_extrapolationto_cumulativeto_incrementalEach tool has a clearly distinct purpose: core calculation (compute_chain_ladder), alternative method (bornhuetter_ferguson), comparison, diagnostics (raw and interpreted), stochastic error, sensitivity, tail extrapolation, data I/O, conversions, license status. No overlap.
All tool names follow a consistent verb_noun pattern with snake_case, e.g., compute_chain_ladder, mack_diagnostics, parse_csv_triangle. The style is uniform and predictable across all 14 tools.
14 tools is well-scoped for an actuarial reserving server, covering core methods, diagnostics, error estimation, sensitivity, tail extrapolation, data I/O, and conversions. No extraneous tools, and each serves a necessary function.
The tool set covers the full typical reserving workflow: data input (parse_csv_triangle, sample_triangle), core deterministic calculation, alternative method, comparison, diagnostics, stochastic error, sensitivity analysis, tail extrapolation, and format conversions. No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Your audit methodology inside Claude: findings, risks, controls and workpapers in your team format.
The statistical analyst in your AI chat — validated, citable, re-runnable analysis of your data.
QuickBooks Online in Claude and ChatGPT: 221 tools, full ledger, multi-company, Canada + US, FR/EN.
A structured financial modeling layer for AI agents. Build, version, and audit financial models without drift, then export to Excel, from Claude or any MCP client. Learn more: https://layerz.cc/for-agents
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/datalattice/mcp-chainladder'
If you have feedback or need assistance with the MCP directory API, please join our Discord server