Skip to main content
Glama

ExchangeRebel — pay-per-call APIs for AI agents (x402 on Solana)

refcheck_precheck

Read-onlyIdempotent

FREE headline check of whether a submitted citation reference resolves in its register (100/day per wallet; pass caller). Submit one reference (PMID, DOI, or arXiv ID plus the claimed title, and optionally authors and year); get the signed verdict line only. Field-by-field detail and the register record are in the paid report. This service verifies that a submitted citation reference resolves in its register and whether the claimed fields match the register's record. It does not judge whether the cited work supports any claim made about it, and it does not grade the cited work.

Input Schema

NameRequiredDescriptionDefault
callerYesSolana base58 wallet of the caller; keys the free allowance (100/day per wallet).
referenceYesThe submitted citation reference: { type?, id, claimed: { title, authors?, year? } }. type is optional (inferred from the id form: PMID, DOI, or arXiv). Submitted content is processed in memory only and never stored.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/open-world, and the description adds genuinely new behavioral facts: a hard 100/day per-wallet allowance, the requirement to pass caller to key that allowance, the deliberately truncated return (signed verdict line only), and in-memory-only processing that never stores submitted content.

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?

Front-loads the free-tier hook and the limit well, but the second sentence largely re-states the first ('verifies that a submitted citation reference resolves in its register'), and the parameter recap duplicates the schema. Two of five sentences do not earn their place.

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?

Covers the essentials an agent needs: cost/limit model, required caller keying, submission shape, redaction rules, and scope exclusions, with the truncated output described since no output schema exists. It does not say what fields the verdict line contains or what a non-resolving verdict looks like, a minor remaining gap.

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%, so the caller and reference shapes — including type inference from PMID/DOI/arXiv and the claimed fields — are already documented. The description restates those forms without adding syntax, formats, or failure behavior beyond what the schema provides.

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 — a free headline check of whether a submitted citation reference resolves in its register — and pins the scope to 'the signed verdict line only' versus the paid full report. An agent can distinguish this from refcheck_check (full report) and refcheck_criteria without opening schemas.

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?

Clearly frames the free-tier use case (100/day per wallet, one reference, verdict line only) and explicitly excludes two jobs it does not do: judging whether the work supports a claim, and grading the work. It never names the paid sibling tool outright, leaving the escalation path to inference.

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