Skip to main content
Glama
Abishai95141

fincon

by Abishai95141

verify_proof

Recomputes every leg subtotal and residual from supplied records to verify a financial proof under a chosen or loop policy, refuting mismatches and claims exceeding tolerance.

Instructions

Re-derive one proof from records you hold. Stateless, and it trusts nothing.

The verifier fetches each record by id, recomputes every leg subtotal and the residual from those records, and compares against what the proof claims. It reads no stored residual, takes its sign convention from policy rather than from the proof, and refuses a proof whose claimed tolerance exceeds the policy ceiling. A proof that names a record you did not supply is refuted, not excused.

Name a loop to verify under that loop's published policy, or hand in a policy of your own. Exactly one — there is no default, because a verification that silently chose a policy would be deciding your constraints for you. The verdict says which you used: a lenient policy you brought along yields a verdict about your constraints and is stamped caller-supplied so it cannot be quoted back as ours.

This call is how you check our work without trusting us. Take a proof out of audit_export, ingest the source files yourself with the published adapter spec, and run it. If it disagrees with us, that is a finding about us.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
loopNo
proofYesEvidence for one match. Immutable once emitted.
policyNo
recordsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It reveals that the tool is stateless, trusts nothing, reads no stored residual, derives sign convention from policy, refuses proofs above the tolerance ceiling, refutes proofs referencing missing records, and stamps caller-supplied verdicts so they cannot be misattributed.

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 long but information-dense, with the core purpose and key behavioral traits front-loaded in the first line. Every paragraph earns its place: policy selection, trust posture, verdict stamping, and workflow all serve the agent's decision-making without fluff.

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 complex tool with nested objects and a low-schema-coverage input, the description is remarkably complete. It covers what the tool recomputes, how it treats missing records, the policy/loop exclusivity, the verdict's caller-supplied marker, and the intended workflow via audit_export — leaving little for an agent to infer or get wrong.

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 description coverage is low (25%), so the description must compensate, and it largely does. It explains the meaning and relationship of proof and records ('fetches each record by id... compares against what the proof claims'), and it gives crucial semantics for loop vs. policy, including the exactly-one rule and absence of a default.

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 and resource: 'Re-derive one proof from records you hold.' It then clarifies the verification mechanism — recompute subtotals and residual from fetched records and compare against the proof's claims — which makes the tool's purpose unmistakable and distinguishes it from close-level or journal-level checks among the siblings.

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?

It gives clear, practical usage context: this is the way to 'check our work without trusting us,' and it tells the caller to pull a proof from audit_export and ingest source files. It also explains the loop-or-policy choice. However, it does not explicitly mention when to prefer an alternative sibling tool or when not to use this tool.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Abishai95141/FinCon'

If you have feedback or need assistance with the MCP directory API, please join our Discord server