Redeal

validate_input

Validate your algorithm input against the deal's contract BEFORE you commit. A commitment binds the exact input bytes — a contract-violating input (e.g. split.v1 valuations not summing to exactly 1000) can never be corrected afterwards and the deal will VOID at the reveal deadline. Always validate first, then compute_commitment_tool, then commit_input. Read-only: nothing is stored or changed.

Input Schema

TableJSON Schema

Name	Required	Description
`input`	Yes	The algorithm input you plan to commit (e.g. {"valuations": {"<item_id>": <points>}} for split.v1 — every party's valuations must sum to exactly 1000). Validated against the deal's algorithm and declared params; nothing is stored.
`deal_id`	Yes	The deal id (d_...).
`invite_token`	Yes	The invite token for YOUR party, from create_deal's response.

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations provided, the description fully discloses the tool's behavioral trait: 'Read-only: nothing is stored or changed.' It also warns of the consequence of using the tool incorrectly (deal VOID at reveal deadline). There is no contradiction with any structured data.

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 two sentences long, front-loaded with the core purpose, and every sentence serves a distinct role (purpose, consequence, ordering, behavioral note). No redundant or extraneous information.

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

Completeness4/5

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

Given the low complexity, 3 required parameters, no output schema, and no annotations, the description covers purpose, usage, behavioral traits, and parameter context. The only minor gap is the absence of any information about the return value (e.g., success/failure/errors), but the tool's role as a validation gate is sufficiently clear for an agent to use it correctly.

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 100%, so the schema already documents each parameter. The description adds value beyond the schema by providing a concrete example of the 'input' format and its constraint, and by reiterating the read-only nature for all parameters. This is a meaningful addition, raising it above the baseline of 3.

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 explicitly states the tool's purpose: 'Validate your algorithm input against the deal's contract BEFORE you commit.' It uses a specific verb ('validate') and resource ('algorithm input against the deal's contract'), and distinguishes it from sibling tools like 'commit_input' by positioning it as a prerequisite step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

The description provides clear guidance on when to use the tool: 'Always validate first, then compute_commitment_tool, then commit_input.' It also explains why (contract-violating input voids the deal) and gives an example of what constitutes a violation (valuations not summing to 1000), making the decision to use this tool unambiguous.

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

All Redeal tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a clear, distinct role in the deal lifecycle: key creation, deal creation, algorithm listing, input validation, commitment computation, committing, revealing, entropy retrieval, certificate fetching, and certificate verification. No two tools appear to do the same thing.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., create_deal, get_certificate, verify_certificate). The verbs and nouns are descriptive and match the tool's function. There is no mixing of conventions.

Tool Count5/5

With 11 tools, the set is well-scoped for the fairness deal domain. Each tool earns its place, covering onboarding, deal creation, input handling, execution, and verification without unnecessary redundancy.

Completeness4/5

The core lifecycle is covered: create key, create deal, inspect algorithms, validate inputs, compute commitments, commit, reveal, fetch entropy for random deals, retrieve certificates, and verify them. The main gap is a tool for counterparties to accept/join a deal using the invite token, but this may be handled outside the MCP server.

Resources

Need Help?