Skip to main content
Glama

Tweedekamer Nl

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Resolution Diff

resolution_diff
Read-onlyIdempotent

Field-by-field diff of TWO markets' settlement clauses (one from each of a and b; either can be Polymarket .com, Polymarket US, or Kalshi) — runs resolution_audit on both sides and compares source, settle time, precision, comparison_basis, and evidence standard. Returns equivalent: "true" only when both sides parsed with enough confidence to compare AND no field conflicts; "false" when a specific conflict was found (differing_fields names which — e.g. ["source","settle_time"] for a Polymarket Bitcoin market settling on Binance's 1-minute candle at noon ET versus a Kalshi KXBTCD market settling on CF Benchmarks' BRTI 60-second average at 5pm EDT — SAME asset, DIFFERENT contract; or ["source","precision"] for Polymarket.com's Chainlink 15-minute TWAP clause (precision "twap_60s_lookback") against Kalshi's 15-minute KXBTC15M clause (precision "60-second trailing average" off CF Benchmarks' BRTI) — different source and a different lookback mechanism, even though BOTH compare an end-of-window average to a start-of-window average, so comparison_basis is EQUAL there and correctly NOT in differing_fields — verified live 2026-10-22, fleet #3447); "unclear" when one or both sides could not be confidently parsed (an absence of evidence is not evidence of equivalence — read raw_clause yourself in that case). comparison_basis is flagged as differing whenever both sides resolved one and they disagree, independent of whether source/precision also matched. Only flags source/evidence_standard as differing when BOTH sides gave a SPECIFIC comparable answer — a named source (e.g. "Associated Press, Fox News, NBC") against a generic one (e.g. Kalshi's "consensus of media organizations") is treated as the same evidence standard, not a conflict, since that is standard election-market boilerplate on both venues. Use this before sizing a polymarket_kalshi_spread pair as a real cross-venue arb, or standalone to sanity-check any two markets you suspect settle on different things.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
aYesFirst market to compare.
bYesSecond market to compare.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / a / properties / venue / enum
      Previous value: -[
-  "polymarket",
-  "kalshi"
-]New value: +[
+  "polymarket",
+  "kalshi",
+  "polymarket-us"
+]
    • changedInput schema / properties / b / properties / venue / enum
      Previous value: -[
-  "polymarket",
-  "kalshi"
-]New value: +[
+  "polymarket",
+  "kalshi",
+  "polymarket-us"
+]
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already cover readOnly/idempotent/non-destructive, but the description adds the behavior that matters: the three-state `equivalent` contract, the rule that comparison_basis differing is evaluated independently, and the deliberate non-flagging of generic-vs-named media sources. It even sets expectations about evidence gaps ('absence of evidence is not evidence of equivalence').

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

Conciseness3/5

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

The core definition is front-loaded correctly, but the body is a single enormous sentence-adjacent block stuffed with two full worked market examples plus provenance ('verified live 2026-10-22, fleet #3447'). The examples do illustrate real edge cases, yet the density and run-on construction make it hard to scan and much of the illustrative detail is expendable.

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?

There is no output schema, so the description carries the return contract and does so fully: it defines all three `equivalent` values and explains `differing_fields` semantics and inclusion rules. It even points at `raw_clause` for the unclear case, which is exactly the missing detail an agent would otherwise need.

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% and both nested objects are documented, so the baseline of 3 applies. The description adds little beyond the enum — it restates that each side is Polymarket, Polymarket US, or Kalshi, which the enum already encodes, and says nothing about market-identifier formats for the `market` string.

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 ('Field-by-field diff of TWO markets' settlement clauses') and immediately scopes it to exactly one market from each of a and b across three venues. It also names the mechanism (runs resolution_audit on both sides) and the compared fields, so an agent can distinguish it from resolution_audit and polymarket_kalshi_spread without opening any schema.

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?

Gives an explicit when-to-use ('before sizing a polymarket_kalshi_spread pair as a real cross-venue arb') plus a standalone case, and tells the agent what to do when the result is 'unclear' — read raw_clause rather than assume equivalence. That is usage guidance and failure handling, not just context.

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

All Tweedekamer Nl toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources