Skip to main content
Glama
Kealu-Labs

kealu-benefits-navigator

Official
by Kealu-Labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Benefit & Insurance Navigator

Kealu Benefits Navigator — Why We Built This

Model-agnostic multi-agent system that discovers government benefits and insurance plans, validates eligibility, and produces prioritized enrollment action plans. Built with Kealu Vector, an enterprise AI workflow orchestrator, and integrated with Google Antigravity via MCP. Kealu Vector supports any LLM provider — our target environment uses Gemini.

The Problem

An estimated $80 billion in government benefits goes unclaimed every year in the United States — not because people don't qualify, but because they can't find or navigate the programs. SNAP alone leaves roughly $13 billion unclaimed annually. Medicaid, CHIP, LIHEAP, Section 8, WIC, TANF — each has its own eligibility rules, application process, income thresholds, and deadlines, spread across federal, state, and county agencies with no single point of entry.

The people who need these programs most are the least equipped to navigate them. A single parent working two jobs doesn't have time to cross-reference 15 programs across 3 government levels, verify which income thresholds use gross vs. net, figure out whether Medicaid expansion applies in their state, or catch that qualifying for one program changes eligibility for another. The alternative — a benefits counselor — costs $100-300 per session, assuming one is available in your area.

This is an information problem. The data exists. The eligibility rules are public. But they're scattered across hundreds of .gov websites, updated on different schedules, and written in language that assumes you already know which program to look for. What's missing is a system that can gather all of it, validate it against your specific situation, and tell you exactly what to do — with the same rigor a professional counselor would apply, but accessible to anyone with a conversation.

Related MCP server: MCP Multi-Agent Server

Interfaces

The benefit navigator can be accessed in two ways:

Interface

Best for

How it works

Web App (web/)

Self-serve users — no setup needed

Next.js 15 chat UI with guided intake, live SSE progress, rendered report

Google Antigravity (MCP)

Developers & power users in an AI IDE

MCP server connects Antigravity to the 5-phase workflow over stdio

Both interfaces run the same underlying Kealu Vector workflow and Python tooling — the web app is an additional entry point, not a replacement.

How It Works

A user provides their household details through either the web app or Antigravity. Through the MCP server, Vector orchestrates a 5-phase workflow where each phase is handled by a specialized agent (Gemini in our target configuration, but Vector is model-agnostic):

                  ┌──────────────┐         ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
                  │  Phase 1     │         │  Phase 3     │    │  Phase 4     │    │  Phase 5     │
┌──────────┐      │  Benefits    ├───┐     │  Evidence    ├───▶│  Eligibility ├───▶│  Action      │
│ Antigrav.├─────▶│  Research    │   ├────▶│  Verification│    │  Validation  │    │  Plan        │
│  (user)  │      └──────────────┘   │     └───────┬──────┘    └──────────────┘    └──────────────┘
└──────────┘      ┌──────────────┐   │             │
                  │  Phase 2     │   │             │
                  │  Insurance   ├───┘             │
                  │  Research    │                 │
                  └──────────────┘                 │
                         ▲                         │
                         │   feedback loop         │
                         │  (on critical errors)   │
                         └─────────────────────────┘

                  ◀── parallel ──▶

  1. Benefits Research — Discovers federal, state, and county assistance programs (SNAP, Medicaid, CHIP, WIC, LIHEAP, Section 8, TANF, etc.) with estimated dollar values

  2. Insurance Research — Compares plans across 6 channels: ACA marketplace, off-marketplace, short-term, health sharing ministries, ICHRA, QSEHRA — with copay-level detail

  3. Evidence Verification — Adversarial fact-checker that independently recalculates FPL, verifies Medicaid expansion status, cross-checks data consistency across phases, and validates every income threshold against reference tables. If critical errors are found, a feedback loop sends corrections back to phases 1 & 2 for re-execution.

  4. Eligibility Validation — Cross-validates all determinations using verified data, detects coverage gaps and income cliffs

  5. Action Plan — Produces a prioritized enrollment plan with deadlines, document checklists, application URLs, and contingency paths

Phases 1 & 2 run in parallel via a dependency DAG. Phase 3 acts as an adversarial checkpoint — if the research agents hallucinated data or made calculation errors, the feedback loop catches it before eligibility determinations are made. Quality gates enforce output completeness and catch vague language.

Why Kealu Vector

Most AI tools give you a single prompt and a single model call. Vector orchestrates multiple specialized agents through structured, multi-phase workflows — each agent has a defined persona, domain context, and quality gates that validate its output before the next phase begins. Vector is model-agnostic: swap the underlying LLM by changing a single configuration value without touching workflow logic, personas, or quality gates.

What makes this different from a prompt chain or a simple agent loop:

  • Parallel execution with dependency DAGs — phases that don't depend on each other run concurrently (benefits research and insurance research run in parallel, cutting wall-clock time in half)

  • Quality gates — 12 gate types (contains, not_contains, model_eval, grounded_claims, etc.) with composite logic. The action planner can't produce "apply soon" — the gate catches vague language and forces specificity

  • Adversarial fact-checking with feedback loops — a dedicated Evidence Verifier agent independently recalculates every FPL percentage, verifies Medicaid expansion status, and cross-checks data consistency. If it finds critical errors, a feedback loop automatically sends corrections back to the research phases for re-execution — agents correct each other, not just flag problems

  • Persona-driven agents — each agent has explicit scope boundaries, a self-verification checklist, and anti-patterns to avoid. The insurance analyst knows to check formulary tiers and ER copays; the action planner knows to never say "contact your state agency" without providing the actual URL

  • Domain context injection — agents receive reference data (FPL tables, Medicaid expansion status, program thresholds) as verified context, not as training data that might be stale or hallucinated

  • Full decision logging — every prompt, output, cost, and quality gate result is logged for audit and debugging

Vector was built for enterprise environments where AI outputs need to be verifiable, auditable, and safe — not just impressive. The same platform has orchestrated 550,000+ lines of audited code for regulated industries through 18-phase code reviews with security analysis — the benefit navigator runs on the same infrastructure, not a hackathon prototype.

Built with Vector

This benefit navigator was itself built using kvr assist, Vector's AI-powered development workflow. The personas, contexts, quality gates, and MCP integration in this repo were developed through Vector's intention-to-outcome alignment — where every task starts with a plan, executes through traceable steps, and produces auditable decision logs. The tool that orchestrates the benefit agents is the same tool that wrote them.

Privacy & Data Sensitivity

Benefits navigation involves sensitive personal information — income, household composition, health conditions, medications, and immigration-adjacent data. While this tool does not store, persist, or transmit Protected Health Information (PHI) and is not a HIPAA-covered entity, the architecture is designed with data sensitivity in mind:

  • No data persistence — user profile data lives only in the workflow run's memory and decision log. Nothing is written to a database or sent to third parties.

  • Local execution — the MCP server runs on the user's machine. Household data flows directly from Antigravity to Gemini via Vector, never through an intermediary service.

  • Auditable outputs — every determination cites its source (.gov URL, FPL table reference, or explicit "unverified" classification). Users can verify claims before acting.

  • No training on user data — Gemini API calls do not use input data for model training.

  • Decision logs — every prompt, agent output, quality gate result, and cost is recorded in append-only JSONL logs. If a user disputes a recommendation, the full reasoning chain is reconstructable. In a production deployment, Vector's enterprise features add encryption (RSA+AES) and cryptographic sealing for tamper-proof audit trails.

In a production deployment, Vector's enterprise features add further controls: data sovereignty zones (restricting which data reaches which model endpoints) and role-based access to audit trails.

Coverage

  • All 50 US states + DC

  • US territories (Puerto Rico, Guam, USVI, American Samoa, CNMI)

  • 2025 Federal Poverty Level tables (48-state, Alaska, Hawaii)

  • Medicaid expansion status tracking (10 non-expansion states)

Architecture

kealu-benefits-navigator/
├── web/                       # Next.js 15 web interface (TypeScript)
│   ├── src/
│   │   ├── app/api/           # Route handlers: session, intake, workflow SSE, report
│   │   ├── components/        # Chat UI, phase tracker, report view, error banner
│   │   ├── lib/               # Session store, KVR runner, intake flow, report assembler
│   │   └── instrumentation.ts # Startup checks + orphan run-directory sweep
│   └── tests/                 # 212 TypeScript tests (Vitest unit/API/integration + Playwright E2E)
├── src/benefits_navigator/    # MCP server (stdlib-only core, pypdf optional)
│   ├── mcp_server.py          # MCP JSON-RPC 2.0 over stdio + tool dispatch
│   ├── marketplace_api.py     # Healthcare.gov Marketplace API client (live plan data)
│   ├── form_filler.py         # Official form filling (pypdf) with worksheet fallback
│   ├── pdf_generator.py       # Zero-dependency PDF worksheet generator
│   ├── forms/                 # Official fillable form templates (4 states)
│   │   ├── CA-SAWS-1.pdf      # California SAWS-1 (CalFresh/Medi-Cal/CalWORKs)
│   │   ├── IL-444-2378B.pdf   # Illinois IL444-2378B (Cash/Medical/SNAP combined)
│   │   ├── NY-LDSS-4826-DD.pdf # New York LDSS-4826-DD (SNAP)
│   │   └── PA-600.pdf         # Pennsylvania PA-600 (Cash/Healthcare/SNAP)
│   ├── __main__.py            # python -m benefits_navigator
│   └── __init__.py
├── workflows/                 # Kealu Vector workflow definitions
│   └── benefits-navigator.yaml # 5-phase parallel workflow with quality gates
├── personas/community/        # Agent persona definitions
│   ├── benefits-researcher.md
│   ├── insurance-analyst.md
│   ├── evidence-verifier.md
│   ├── eligibility-analyst.md
│   └── action-planner.md
├── contexts/community/        # Domain knowledge contexts
│   └── benefits-navigator.md   # FPL tables, program reference, quality standards
├── tests/                     # 79 Python BDD tests (pytest-bdd) + 3 integration tests
│   ├── features/              # Gherkin scenarios
│   └── step_defs/             # Step implementations
├── .env.example               # CMS API key template
└── .env                       # Your API key (gitignored)

Prerequisites

Setup

Web App

cd web
cp .env.example .env.local          # Add CMS_API_KEY if available
npm install
npm run dev                          # http://localhost:3000

Verify readiness:

curl http://localhost:3000/api/health
# { "kvr": "ok", "cms_api_key": "set", "version": "0.225.0" }

Deployment note: The web app streams SSE connections that stay open for up to 30 minutes while KVR runs the 5-phase workflow. Most managed platforms (Vercel Hobby, Railway free tier) impose per-request timeouts of 30–300 seconds that will terminate long-running workflows. Self-host using npm run build && npm start, or use a platform that supports long-lived streaming responses (Vercel Pro with maxDuration = 0, Fly.io, Render). See web/README.md for full deployment guidance.

MCP Server (Python)

# Create virtual environment
python -m venv .venv
source .venv/bin/activate

# Install in development mode
pip install -e .

# Configure CMS API key (optional — enables live Healthcare.gov plan data)
cp .env.example .env
# Edit .env and add your CMS_API_KEY

Usage

Web App

Navigate to http://localhost:3000 after running npm run dev from the web/ directory. The app guides you through a tiered intake conversation and displays live workflow progress and a rendered report — no account required.

With Google Antigravity (MCP)

Add to ~/.gemini/antigravity/mcp_config.json:

{
  "mcpServers": {
    "benefits-navigator": {
      "command": "/bin/zsh",
      "args": ["-c", "set -a && [ -f ~/.env ] && source ~/.env; [ -f /path/to/kealu-benefits-navigator/.env ] && source /path/to/kealu-benefits-navigator/.env && set +a && exec /path/to/kealu-benefits-navigator/.venv/bin/python -m benefits_navigator"],
      "cwd": "/path/to/kealu-benefits-navigator"
    }
  }
}

Then ask Antigravity: "I need help finding benefits and insurance options for my family"

The MCP server guides the conversation through a tiered intake flow — collecting ZIP code, income, household composition, medications, providers, and budget — before triggering the full 5-phase analysis.

With Kealu Vector CLI

kvr run benefits-navigator \
  --var "household_profile=Single parent, 2 kids ages 4 and 9, $42k income" \
  --var "zip_code=77001" \
  --var "state=Texas" \
  --var "county=Harris County"

Tools Exposed via MCP

Tool

Data source

Description

navigate_benefits

Vector 5-phase workflow

Full analysis with guided intake flow

check_eligibility

CMS API + Vector

Single-program eligibility check, enriched with live APTC/FPL/Medicaid data. Accepts optional zip_code for county/state resolution.

compare_insurance_plans

CMS Marketplace API

Real plan names, premiums, deductibles, and subsidy calculations from Healthcare.gov

generate_application_draft

Official forms + local PDF

Fills real government forms (CA SAWS-1) or generates preparation worksheets

When CMS_API_KEY is configured, compare_insurance_plans returns real marketplace plans with APTC-adjusted premiums and check_eligibility includes live CMS data (FPL percentage, APTC amount, state Medicaid thresholds). Without the key, both fall back gracefully to Vector's AI-powered analysis.

After analysis, generate_application_draft produces a pre-filled application PDF. For states with official fillable forms (CA, IL, NY, PA), it fills the actual government form — checking program eligibility boxes, pre-filling location and date fields. For other states, it generates an Application Preparation Worksheet. The system doesn't just advise — it takes action.

Supported official forms:

State

Form

Programs

California

SAWS-1

CalFresh, Medi-Cal, CalWORKs

Illinois

IL444-2378B

SNAP, Medicaid, Cash Assistance

New York

LDSS-4826-DD

SNAP

Pennsylvania

PA-600

SNAP, Medicaid, Cash Assistance

Healthcare.gov Marketplace API

The CMS Marketplace API provides:

  • Real plan search — actual plan names, issuers, premiums, deductibles, and out-of-pocket maximums for any US ZIP code

  • APTC subsidy calculation — household-specific tax credit amounts based on income and FPL

  • CSR eligibility — cost-sharing reduction levels that lower deductibles on Silver plans

  • Medicaid/CHIP screening — flags households that may qualify before they spend time on marketplace plans

  • Provider/drug coverage — API endpoints available for verifying doctor and medication coverage (not yet wired into MCP tools)

Architecture & Decision Records

See ARCHITECTURE.md for the full system diagram, data flow, key boundaries, and 7 Architecture Decision Records covering zero-dependency design, CMS API integration, domain isolation, adversarial verification, BDD test strategy, progress streaming, and tiered intake flow.

Technologies

  • Next.js 15 + TypeScript — Web interface with chat UI, SSE streaming, and server-rendered report (under web/)

  • Gemini (target environment) — Powers all 5 specialized agents through Kealu Vector's model-agnostic orchestration

  • Google Antigravity — Agent-first IDE providing an alternative conversational interface via MCP

  • Healthcare.gov Marketplace API — Live insurance plan data, subsidy calculations, and eligibility estimates from CMS

  • MCP (Model Context Protocol) — stdio-based JSON-RPC 2.0 connecting Antigravity to the benefit navigator

  • Kealu Vector — Enterprise workflow orchestrator with parallel phases, quality gates, persona-driven agents, and decision logging

Available Tools

4 tools
check_eligibilityA

ALWAYS use this tool to check eligibility for a specific government program (Medicaid, CHIP, SNAP, WIC, LIHEAP, Section 8, TANF, ACA Marketplace, etc.). Validates against 2025 FPL thresholds and state-specific rules including Medicaid expansion status.

ParametersJSON Schema
NameRequiredDescriptionDefault
programYesProgram to check: Medicaid, CHIP, SNAP, WIC, LIHEAP, Section 8, TANF, ACA Marketplace, etc.
zip_codeNo5-digit ZIP code for county/state resolution and Medicaid lookup
household_profileYesHousehold details: income, size, ages, location

TDQS

A4.2/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. Discloses validation against 2025 FPL thresholds and state-specific rules, including Medicaid expansion status, which adds 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with 'ALWAYS', no wasted words. Efficient and direct.

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 3 parameters, 2 required, no output schema, and no annotations, description covers purpose and validation logic. Lacks detail on return values or errors but is adequate for the tool's complexity.

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 baseline is 3. Description adds value by listing programs and mentioning FPL thresholds but does not elaborate on parameter formats beyond schema.

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?

Description clearly states the tool checks eligibility for specific government programs, lists program examples, and mentions validation criteria, distinguishing it from siblings like compare_insurance_plans.

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?

Explicitly says 'ALWAYS use this tool' for eligibility checks, providing clear context. Does not explicitly state when not to use, but sibling tools imply alternatives.

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

compare_insurance_plansA

ALWAYS use this tool to compare health insurance plans. Analyzes all 6 channels: ACA marketplace (with APTC subsidy calculation), off-marketplace carrier plans, short-term/gap insurance, health sharing ministries, ICHRA, and QSEHRA. Calculates cost-of-care scenarios and identifies optimal plan by household needs.

ParametersJSON Schema
NameRequiredDescriptionDefault
zip_codeYesZIP code for marketplace plan lookup
providersNoCurrent doctors/providers for network matching
medicationsNoCurrent medications for formulary matching (drug name, dosage, frequency)
health_needsNoChronic conditions, anticipated procedures, mental health needs
usage_patternNoAnnual usage: PCP visits, specialist visits, ER visits, urgent care
premium_budgetNoMaximum monthly premium budget
household_profileYesHousehold details: income, size, ages, location
network_preferenceNoHMO acceptable? Need PPO? Referral concerns?
pharmacy_preferenceNoPreferred pharmacy (CVS, Walgreens, mail-order)

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral transparency. It describes what the tool does (analyzes, calculates, identifies) and the scope (6 channels), but does not disclose return format, error handling, rate limits, or required permissions. The description provides adequate insight into functionality but lacks depth on behavioral traits.

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 four sentences and front-loaded with the imperative purpose. Every sentence adds value: the first states usage, the second enumerates channels, and the third describes outcomes. No redundancy or filler.

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

Completeness3/5

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

Given no output schema, the description should explain what the tool returns. It mentions 'identifies optimal plan' but does not specify the output format or whether it provides a comparison list. Parameter descriptions are complete in schema, but the tool's overall behavior could be more fully specified.

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 baseline is 3. The tool description does not add additional meaning beyond the schema's parameter descriptions. It does not explain how parameters map to the 6 channels or provide usage examples. The schema already describes each parameter adequately.

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 purpose: to compare health insurance plans across 6 specific channels. It uses a strong verb ('compare') and explicitly lists the value proposition (calculates cost-of-care scenarios, identifies optimal plan). This distinguishes it from sibling tools like check_eligibility and generate_application_draft.

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?

The description explicitly instructs 'ALWAYS use this tool' for comparing health plans, indicating its primary use case. It implies usage context by listing the channels and scenarios. However, it does not provide explicit when-not-to-use guidance or mention alternatives, but the sibling tool names suggest distinct purposes.

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

generate_application_draftA

Generate a pre-filled PDF application for benefit programs. For states with official fillable forms (e.g. California SAWS-1), fills the actual government form. For other states, generates an Application Preparation Worksheet. Call AFTER navigate_benefits. Returns the file path to the generated PDF.

ParametersJSON Schema
NameRequiredDescriptionDefault
stateNoUS state (e.g. 'California', 'TX')
countyNoCounty name (e.g. 'Los Angeles County')
zip_codeNo5-digit ZIP code
income_typeNoEmployment, self-employment, unemployment, etc.
health_needsNoHealth conditions and needs
workflow_outputYesThe full text output from navigate_benefits. Pass the complete analysis so the PDF can extract eligible programs and document requirements.
household_profileYesHousehold details (same as navigate_benefits)

TDQS

A4/5.0
Behavior3/5

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 the tool generates a PDF and returns a file path, and that behavior varies by state. It does not mention permissions, error handling, or side effects, but is adequate for a file-generation tool.

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 concise: two sentences plus a usage note. Every sentence provides essential information, front-loading the main action and key behavioral distinction. No wasted words.

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?

The description covers the tool's purpose, when to call, state-specific behavior, and return value. Lacking details on error cases or file lifecycle, but given the complexity and no output schema, it is reasonably complete.

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%, so baseline is 3. The description does not add new meaning beyond the schema; it reiterates that workflow_output should be from navigate_benefits, but this is already in the schema description. No additional constraints or examples.

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 generates a pre-filled PDF application, distinguishing it from sibling tools like navigate_benefits (which explores programs) and check_eligibility (which checks eligibility). It specifies that for states like California it fills official forms, otherwise generates a worksheet, providing concrete scope.

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?

Explicitly states 'Call AFTER navigate_benefits', providing clear usage context. However, it does not explicitly mention when not to use or alternatives, but the ordering instruction is strong guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv0.1.0
    • First observedcheck_eligibility
    • First observedcompare_insurance_plans
    • First observedgenerate_application_draft
    • First observednavigate_benefits
Deploy Server
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

TDQS

A4.2/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: navigate_benefits handles initial profiling, check_eligibility checks program eligibility, compare_insurance_plans compares insurance options, and generate_application_draft creates applications. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case: check_eligibility, compare_insurance_plans, generate_application_draft, navigate_benefits. The verbs are action-oriented and the nouns clearly indicate the target.

Tool Count5/5

With 4 tools, the set is concise and well-scoped for a benefits navigator. Each tool covers a necessary step in the benefits workflow without redundancy or unnecessary tools.

Completeness4/5

The tool set covers the key stages: navigation, eligibility checking, insurance comparison, and application generation. A minor gap is the lack of tools for submitting applications or tracking status, but the core workflow is well-supported.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers