BackNine Life Insurance

get_life_quote_requirements

Read-onlyIdempotent

Get required inputs for anonymous US life insurance and long-term-care quotes across enabled non-annuity product types, including product-specific inputs, solves, health labels, and rider filters. No name, email, phone, SSN, account, or existing application is needed.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_life_quote_requirements"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 18, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuinely new behavioral context: the operation is anonymous, requires no PII, is restricted to non-annuity product types, and only surfaces enabled products. It does not describe the shape of the response, but the annotation bar is already met.

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?

Two sentences, tightly front-loaded: scope and returned content first, then the calling constraint. No filler, no repetition of the title or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no parameters and no output schema, the description must describe what comes back, and it does list the return categories (product-specific inputs, solves, health labels, rider filters). It stops short of explaining the structure or how to interpret those categories, a minor gap for a zero-arg discovery tool.

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

Parameters4/5

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to clarify beyond confirming no input is required, which the anonymity sentence effectively does.

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+resource ('Get required inputs for ... quotes') and narrows scope precisely ('anonymous US life insurance and long-term-care quotes across enabled non-annuity product types'). An agent can distinguish this requirements-lookup tool from sibling quoting tools like quote_life_insurance without opening a schema.

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?

Usage context is clear: this is the prerequisite step that enumerates inputs before quoting, and the negative prerequisites ('no name, email, phone, SSN, account, or application needed') tell the agent when it can safely call it. However, no sibling tool is named as an alternative and there are no explicit exclusions beyond 'non-annuity'.

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

All BackNine Life Insurance tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?