Skip to main content
Glama

File a complaint about a settled paid transaction

file_complaint
Idempotent

File a complaint about a transaction you were a party to. Free, no account. Two calls: send your filing WITHOUT a signature to receive the exact statement to sign plus an admissibility verdict, then sign that exact string from the address you claim (personal_sign / EIP-191) and call again with the signature. Admissible when you are a proven party to a SETTLED matter: the payment reached the payee, the exchange hit a terminal on-chain state, or the funds have not moved for thirty days past the deadline the seller announced. Nothing is admissible while funds are genuinely in play. Both sides may file. The counterparty is notified and replies for free, permanently linked to your file. Verification and publication are done by hand.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
roleYesYour side of the transaction
accountYesYour dated account of what happened (80 to 6000 characters)
addressYesThe 0x address you control and will sign with
networkYesCAIP-2, e.g. eip155:8453
filed_onYesYYYY-MM-DD, the date of the statement you sign
signatureNoSecond call only — the 65-byte hex signature over the exact statement returned by the first call
matter_urlNoOptional https URL where that reference can be read
filer_contactYesPrivate contact for verification — never published
settled_basisYesWhy the matter is settled
subject_labelYesThe seller, resource or offer as it is publicly named
terminal_stateNoRequired for terminal_onchain_state
matter_referenceYesTransaction hash, payment nonce or exchange id, as published
settled_evidenceYesHow a third party confirms the matter is settled without believing you
announced_deadlineNoRequired for frozen_past_deadline — YYYY-MM-DD, the deadline the seller or platform announced
counterparty_addressYesThe other 0x address of the same transaction
counterparty_channelNoWhere the counterparty can be notified
counterparty_channel_kindYesDecides the reply window: machine 1h, human 24h, none published with the failed notice

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations indicate write operation (readOnlyHint=false) and idempotency (idempotentHint=true). Description adds that filing requires two calls, counterparty is notified, and verification is manual, which goes beyond annotations.

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?

Front-loaded with purpose, then process, conditions, and outcomes. Each sentence adds value, though the description is somewhat lengthy.

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?

Explains two-call workflow and admissibility but does not describe what the first call returns beyond 'exact statement' and 'admissibility verdict', nor the output of the second call. Lacks error handling or rate limits.

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. Description provides workflow context but does not add significant meaning beyond schema descriptions for individual 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?

Description clearly states verb 'file' and resource 'complaint about a transaction you were a party to', specifying it's for settled paid transactions. Distinguishes from sibling 'check_complaints' which reads complaints.

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?

Explains two-call process, admissibility conditions, and that both sides may file. Lacks explicit when-not-to-use and direct comparison to alternatives like 'talk_to_representative' or 'check_complaints'.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources