fahali-mcp

fahali_unsubscribe_risk

DestructiveIdempotent

Idempotently disable a monitor-only risk subscription to stop new queueing and retries; fence pending work and keep audit visible. Use a new idempotency key for any changed request.

Instructions

Idempotently disable a monitor-only risk subscription. New queueing and retries stop; pending work is fenced and its audit remains visible. A request already past the dispatch boundary may arrive once, so receivers must deduplicate by X-Fahali-Delivery. Retry an identical request with the same idempotency key; use a new key for any change.

Input Schema

Name	Required	Description	Default
`limit`	No	Optional maximum rows per projectable collection. Audit has no MCP projection cap; brief defaults to 3 and standard to 12.
`since`	No	Optional lower timestamp bound for returned row collections.
`detail`	No	Response depth. audit is the full-fidelity default; brief and standard are explicit compact projections.	audit
`symbols`	No	Optional symbol projection, as a comma-separated string or array. Rows without instrument identity are not discarded.
`idempotency_key`	Yes	Required retry identity for this write. Reuse only for an identical owner, operation, and request; a changed request with the same key fails closed.
`subscription_id`	Yes
`include_withheld`	No	Include full withheld-row detail. Defaults true with audit; explicitly set false only for a compact projection.

Output Schema

Name	Required	Description
`asOf`	No
`auth`	No	Credential lifetime visible to the caller. OAuth secondsRemaining lets an autonomous agent refresh before a multi-call workflow is interrupted.
`claim`	No	Fahali dictionary claim (shared/fahaliDictionary.ts). Read `kind` FIRST: 'abstention' means no assertion was made and `reason` says why — never read an abstention as a neutral or zero result. `basis` says what the claim rests on. Absent or null means this response path does not yet emit a claim; treat that as unknown, not as agreement.
`delta`	No
`items`	No
`scope`	No
`watch`	No
`status`	Yes
`absence`	No	Why no actionable finding is present: measured_empty, user_empty, no_coverage, source_unverified, stale, withheld, source_error, auth_failure, or entitlement_required.
`verdict`	No
`watches`	No
`decision`	No
`conflicts`	No
`dataState`	Yes
`mcpStatus`	No	Normalized MCP result status. The endpoint's original status vocabulary remains in `status` and `sourceStatus`.
`refreshed`	No
`requestId`	No
`verdictId`	No
`nextCursor`	No
`validUntil`	No
`claimPolicy`	No	Typed constraints for safe use. Metadata, not a prompt or instruction channel.
`idempotency`	No
`instruments`	No	Resolved or explicitly partial instrument identities. A missing venue carries an ambiguity warning.
`nextActions`	No	Registry-validated follow-up calls. Missing tools, invalid arguments, unresolved placeholders, and disabled tools are omitted.
`sourceError`	No	The upstream endpoint's exact error text/code before normalization, when one was present.
`sourceScope`	No
`decisionHash`	No
`evidenceHash`	No
`sourceStatus`	No	The upstream endpoint's exact status before the MCP envelope normalizes transport success/error.
`subscription`	No
`agentBriefing`	No	Audit-only narrative projection. Present only when detail='audit'; compact responses do not duplicate structured data as prose.
`claimValidity`	No	Validity of the selected binding claim only, calculated after filtering, projection and row selection. Sibling rows cannot determine it.
`operatingMode`	Yes
`responseState`	No
`schemaVersion`	No
`signingSecret`	No
`subscriptions`	No
`authorityState`	No
`sourceDecision`	No
`symbolCoverage`	No	Conservation ledger satisfying requested = returned + withheld + notReturned for requested-symbol calls.
`evidenceQuality`	No
`responseControl`	No
`sourceDataState`	No	The upstream endpoint's exact data-state value before endpoint-aware classification.
`evidenceSnapshot`	No	Compact immutable source snapshot needed to verify evidenceRef integrity on delta responses.
`recordMatchReason`	No	Why matchedTrackRecord is present or null. A null record is never evidence of safety or engine failure.
`signingSecretNote`	No
`matchedTrackRecord`	No	A judged record only when engine, horizon, regime/instrument class, and claim family match this response. `state` is one of: `measured` (a stratum cleared the publishability gate — `stratum` carries engine, horizon tier, bar regime, recall, precision, base rate, base-rate lift, median lead hours, effective sample, warned events and the measurement date); `withheld` (the gate ran and refused — `reason` says why, in words); `unavailable` (the record could not be read at all — an infrastructure failure that says nothing about the record). It is ONE stratum selected by recall, never a platform-wide accuracy. Null means no exact record match; read recordMatchReason.
`methodologyVersion`	No
`confidenceSemantics`	No	Every confidence-bearing value with its score type, scale, calibration status, and probability flag.
`decisionEligibility`	No	Fail-closed binding-authority policy. WITHHELD means source evidence remains available for audit while normalized direction, actionability and execution fields are revoked.
`directionEligibility`	No	Current market-direction eligibility. Direction is authorized only by an exact, eligible producer stratum (canonical_verdict, canonical_symbol_verdict, committee_verdict) — read bindingAuthority to see which one bound. Widening WHO may bind did not weaken WHAT binding requires: the named producer must still hold a matching horizon/class/family record on a verified-only judged population, so an authority without a record still cannot bind.
`executionEligibility`	No	Fail-closed execution boundary. Portfolio monitoring tools always return WITHHELD with MONITOR_ONLY_NO_EXECUTION_AUTHORITY while Fahali has no capital path.
`legacyFieldSemantics`	Yes
`outputClassification`	Yes
`monitoringEligibility`	No	Current portfolio-monitoring validity based on captured identity, freshness, integrity, and the caller-supplied monitoring policy. ELIGIBLE authorizes observation/delivery only, never financial action.
`sourceEvidenceQuality`	No
`currentActionEligibility`	No	Current eligibility of an immutable historical portfolio verdict. It never mutates the stored judgment being replayed.
`sourceConfidenceSemantics`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.28.1Oct 29, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the bar is lower, yet the description still adds real substance: new queueing/retries cease, pending work is fenced, the audit trail stays visible, and an in-flight request may arrive once requiring dedup by X-Fahali-Delivery. That is exactly the at-least-once plus partial-failure detail an agent needs before calling a destructive write.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

Four sentences, front-loaded with the action and its effect before the delivery and retry caveats, with essentially no filler. It is dense with domain jargon ('fenced', 'dispatch boundary') but each clause carries distinct behavioral information.

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

Completeness5/5

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

For a destructive, open-world write with seven parameters and an output schema present, the definition covers what stops, what survives, what can slip through, and how to retry safely. Nothing an agent needs to call it correctly is missing, and return-value explanation is correctly left to the output schema.

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?

Schema coverage is 86%, so the baseline is 3 and the schema already documents limit, since, detail, symbols and include_withheld. The description still adds meaning for idempotency_key beyond the schema's wording by framing reuse around 'identical request' and warning that a changed payload with the same key fails closed, though it says nothing about subscription_id or the projection parameters.

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?

States a specific verb and resource — 'Idempotently disable a monitor-only risk subscription' — and the qualifier 'monitor-only' narrows the scope precisely. Reading the name and this sentence is enough to distinguish it from fahali_subscribe_risk and fahali_update_subscription 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives solid operational guidance for retries ('retry an identical request with the same idempotency key; use a new key for any change') and receiver-side dedup, but never states when to choose this over the sibling fahali_update_subscription or fahali_list_risk_subscriptions. Usage is implied by the verb rather than contrasted with alternatives.

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

Deploy Server