FAHCE Integrity Repair

fahce_integrity_repair_bundle

Idempotent

For a combined integrity review, return diagnosis, bounded proposed plan, submitted-answer verification state and receipt; no revised answer is executed or verified. Production x402 payments, delivery of purchased results, gateway settlement and seller receipt were verified end to end on October 14, 2026. Paid REST determinations persist immutable receipts and meter usage. MCP discovery only; tools/call cannot purchase. No human authority or external execution is granted. Example arguments: {"request":{"schema":"FAHCE_MACHINE_REQUEST_V1","candidate_output":"Service is ready.","evidence":[{"id":"deployment_log","kind":"log","source_label":"independent deployment log","text":"Deployment failed."}]}}

Input Schema

TableJSON Schema

Name	Required	Description	Default
`request`	Yes	Send this request object alone to the paid REST endpoint. Entire JSON must fit 524288 UTF-8 bytes, including MCP wrapper, labels and escaping; per-field ceilings cannot all be used together. Character limits use UTF-16 code units.
`idempotency_key`	No	Optional REST Idempotency-Key; bind unchanged operation, input and authorization. Reuse conflicts on changes; recover saved results instead of paying again.

Output Schema

TableJSON Schema

Name	Required	Description
`repair`	Yes
`schema`	Yes
`billing`	Yes
`binding`	No
`receipt`	Yes
`authority`	No
`diagnosis`	Yes
`operation`	Yes
`input_hash`	Yes
`request_id`	Yes	Determination UUID, identical to receipt.case_id and receipt.run_id. Use this UUID as receipt_id in GET /api/v1/receipts/{receipt_id}. Error-envelope request_id is a separate HTTP trace; use its receipt_id when present.
`verification`	Yes
`execution_state`	No
`next_safe_action`	Yes
`evidence_provenance`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedOct 18, 2026

addedInput schema / properties / idempotency_key / description

Added value: +"Optional REST Idempotency-Key; bind unchanged operation, input and authorization. Reuse conflicts on changes; recover saved results instead of paying again."

changedInput schema / properties / request / description

Previous value: -"The entire UTF-8 encoded JSON body must fit within 524288 bytes (512 KiB), including all fields, labels, escaping and JSON overhead. Per-field maxima are independent ceilings; they cannot all be used at once. MCP includes its JSON-RPC wrapper in the same body ceiling. Character limits are UTF-16 code units."New value: +"Send this request object alone to the paid REST endpoint. Entire JSON must fit 524288 UTF-8 bytes, including MCP wrapper, labels and escaping; per-field ceilings cannot all be used together. Character limits use UTF-16 code units."

addedInput schema / properties / request / properties / evidence / description

Added value: +"Caller-supplied records; sources are not authenticated or fetched. An empty array supplies no corroboration."

addedInput schema / properties / request / properties / evidence / items / properties / claim_bearing / description

Added value: +"True marks candidate claims, not corroboration. False or omission does not override candidate-source labels."

addedInput schema / properties / request / properties / evidence / items / properties / id / description
```
Added value: +"Unique evidence identifier within this request."
```
addedInput schema / properties / request / properties / evidence / items / properties / kind / description
```
Added value: +"Record format category, not a trust level."
```
addedInput schema / properties / request / properties / evidence / items / properties / source_label / description
```
Added value: +"Source attribution; candidate/output labels mark untrusted claims, not independent proof."
```
addedInput schema / properties / request / properties / evidence / items / properties / text / description
```
Added value: +"Record content to review; never payment authorization as semantic proof."
```

changedInput schema / properties / request / properties / expected_output / description

Previous value: -"Optional response-contract and repair-target context for all operations, including Diagnose. Supported response-format directives (for example, Return JSON) and implemented explicit constraints can affect the diagnosis. Ordinary matching or mismatching factual text is not compared for string equality and is not a trusted answer oracle or supporting evidence; supply independent evidence for factual claims."New value: +"Optional format/constraint and repair-target context for all operations, including Diagnose. Recognized directives (e.g. Return JSON) can affect diagnosis. Factual text is not compared for string equality or trusted as evidence; supply independent records."

addedInput schema / properties / request / properties / schema / description
```
Added value: +"Request contract identifier; use this exact value."
```

First observedOct 15, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, but the description adds real behavioral context: no revised answer is executed or verified, paid determinations persist immutable receipts and meter usage, no human authority or external execution is granted, and idempotency-key reuse conflicts should recover saved results rather than re-pay. The dated payment-verification sentence is promotional rather than behavioral disclosure.

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

Conciseness2/5

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

The purpose is front-loaded and the execution constraints are useful, but a full sentence about production x402 payments being 'verified end to end on October 14, 2026' is dated promotional noise that does not help an agent select or invoke the tool. Sizeable portions of the description do not earn their place.

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?

Output schema exists so return values need no explanation, and the no-execution guarantee plus receipt/idempotency behavior cover the key non-obvious traits of this paid, non-read-only tool. However, the meaning and limits of the 'bounded proposed plan' are left vague, and the dated claims risk confusing the agent about what is actually verified.

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% and the nested request object is thoroughly documented in the schema itself, so the baseline is 3. The description's example arguments illustrate the request shape but add no semantics beyond what the schema already explains.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a concrete verb and resource set: a combined integrity review returning diagnosis, a bounded proposed plan, verification state and receipt. 'Combined' implies it spans the three sibling operations, but it never names fahce_diagnose_integrity, fahce_plan_bounded_repair or fahce_verify_repaired_output to make the distinction explicit.

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?

'For a combined integrity review' and 'MCP discovery only; tools/call cannot purchase' imply when the tool applies and one hard constraint, but there is no explicit routing guidance telling the agent when to use this bundle instead of calling the three siblings individually, nor any stated prerequisites.

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

All FAHCE Integrity Repair tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?