Tool registry

Living inventory of every Florence-callable tool, its backing deterministic endpoint, data classification, allowed auth contexts, eval coverage, and status.

This document is updated as part of every PR that adds, modifies, or removes a tool. See adding a tool. CI asserts registry-file parity with the code registry at src/lib/florence/tools/registry.ts (implemented alongside the runtime spike).

Legend
Class	Highest data classification the tool's output may carry: Public, PHI, PII, FTI, App (application payload).
Auth	Allowed auth contexts. A = anonymous, M = authenticated_member, G = authenticated_agent, X = authenticated_admin.
Cache	Result cache TTL (seconds). — = not cacheable.
Status	stable / beta / planned / deprecated / archived.

api_* — deterministic platform

Consumer / pre-enrollment (anonymous + authenticated_member)

Tool	Backing endpoint	Input summary	Output summary	Class	Auth	Cache	Status	Tracking
api_search_plans	/api/plans	zip, household, income, preferences	Plan list (top-N compact)	Public–PII	A, M, G	600 s	planned	#61
api_check_eligibility	/api/eligibility	household, income, state	Eligibility + subsidy estimate (self-attested)	PII (not FTI pre-enrollment — self-attested)	A, M, G	600 s	planned	#61
api_get_plan_detail	(Phase E, #53) /api/plans/[id]	planId, year, csrTier?	Full plan detail incl. puf.* (base + csrVariants[tier] SBC scenarios when csrTier passed). See Knowledge: SBC scenarios & CSR for how Florence narrates the numbers.	Public	A, M, G	3600 s	planned	#53
api_check_drug_coverage	(Phase C, #17) /api/drug-coverage	planId(s), drug name or RxCUI	Coverage + tier + cost-sharing per plan	PHI	A (self-declared), M, G	300 s	planned	#17
api_check_provider_network	(Phase D, #18) /api/provider-network	planId(s), provider NPI or name + zip	In-network / out-of-network per plan	PHI	A (self-declared), M, G	300 s	planned	#18

⚠️ SBE data-lookup gap (ENG-410) — provider name-search → coverage for CA. The live tools (check_drug, find_doctors/suggest, check_provider in packages/shared/src/florence/tools.ts) hit per-state backends — see SBE vs FFM data lookup. check_drug ✅ and find_doctors/suggest ✅ work for CA; check_provider ❌ returns NotCovered for CA because it discovers via NPPES (NPPES NPI) but CA coverage data is Symphony-providerId-keyed. Fix scoped in ENG-410 (route CA provider discovery through /api/providers/search-ca). Inline ⚠️ SBE GAP (ENG-410) markers are at the two code sites: coverAcrossAllPlans() and the check_provider autocomplete call.

Member-authenticated

Tool	Backing endpoint	Input summary	Output summary	Class	Auth	Cache	Status	Tracking
api_get_member_profile	(Phase 5) /api/members/me/profile	(context only)	Member profile incl. meds, providers, preferences	PHI + PII	M	—	planned	#47
api_get_member_plan_details	(Phase 5) /api/members/me/plan	(context only)	Current plan + deductible progress + MOOP status	PHI + FTI (confirmed APTC)	M	300 s per member	planned	#47
api_get_member_coverage_events	(Phase 5) /api/members/me/coverage-events	date range	Claims, authorizations, status	PHI	M	60 s per member	planned	#47
api_initiate_sep_workflow	(Phase 5) /api/members/me/sep	life event type, date	SEP eligibility + next steps	PHI	M	—	planned	#47
api_request_renewal_analysis	(Phase 5) /api/members/me/renewal-analysis	(context only)	Current vs. alternatives comparison	PHI + FTI	M	3600 s per member	planned	#47

Agent-authenticated

Tool	Backing endpoint	Input summary	Output summary	Class	Auth	Cache	Status	Tracking
api_list_my_assigned_members	(Phase 5) /api/agents/me/members	filter, pagination	Assigned members list (summary)	PHI + PII	G	60 s per agent	planned	#47
api_get_member_full_history	(Phase 5) /api/agents/me/members/[id]/history	memberId (must be assigned)	Full member history incl. conversations, events	PHI + PII	G, X	—	planned	#47
api_compose_member_message	(Phase 5) /api/agents/me/members/[id]/compose	memberId, draft	Saved draft (not sent)	PHI	G	—	planned	#47
api_draft_sep_letter	(Phase 5) /api/agents/me/members/[id]/sep-letter	memberId, life event	Draft letter (legal form)	PHI	G	—	planned	#47
api_assign_escalation	(Phase 5) /api/agents/me/escalations	escalationId, memberId	Assignment confirmation	Audit	G, X	—	planned	#47
api_view_audit_trail	(Phase 5) /api/agents/me/audit	memberId + filters	Audit records (read-only)	Audit	G, X	—	planned	#47

Escalation (available to every mode)

Tool	Backing endpoint	Input summary	Output summary	Class	Auth	Cache	Status	Tracking
api_escalate_to_human	v1: email + Mongo florence_escalations. Phase 5: admin-dashboard queue.	conversationId, reason, urgency, summary	Escalation ID	PHI	A, M, G	—	planned	#61

ui_* — frontend state

Tool	Target	Input summary	Effect	Auth	Status
ui_set_plan_filter	/plans page filter state	zip, household, income, metal tier, drug list, provider list	Updates filter; triggers re-search	A, M, G	planned
ui_open_plan	/plans page	planId	Expands the plan card	A, M, G	planned
ui_highlight_field	any page	field selector, reason	Highlights + scrolls to a form field	A, M, G	planned
ui_start_intake_section	/enrollment	section name	Navigates to intake section	A, M	planned
ui_show_comparison	anywhere	planIds	Opens side-by-side comparison view	A, M, G	planned

Archived tools

None yet. When tools are removed (see adding-a-tool §Deprecating), they move here with the removal date and the eval-bundle archive path.

Evolution notes

• Drug coverage (api_check_drug_coverage) is blocked on Phase C ingestion (#17). The puf.formularyId is already ingested; the UI + per-issuer crawl is the unblocking work.
• Provider network (api_check_provider_network) is blocked on Phase D ingestion (#18). The puf.networkId is already ingested; the sharded collection + UI is the unblocking work.
• Member-side tools all block on AWS migration (#47) and the agent / member auth roll-out (Phase 5).
• Agent-side tools additionally block on the NIPR validation + ID-verification path described in the agent platform architecture.
• Voice does not add tools. Voice is an input/output affordance on the same runtime with the same tool surface.

How to read this registry

If you're evaluating whether Florence can answer a given question, trace:

1. What factual claims does the answer require?
2. Which tool(s) produce those claims?
3. Are those tools stable? If planned or beta, Florence should not be asked this question in production yet, or must escalate.
4. Is the user's auth context in the tool's allowlist?
5. Does the tool's output class conflict with any downstream destination (rare for Florence-only flows; matters when the Florence response feeds an ui_* tool that surfaces data in a UI region subject to its own classification)?

The registry is the answer to "why does Florence know that?" — every factual answer traces to a tool in this table, and every tool traces to a deterministic endpoint.