Skip to main content
Glama

agentdata-nl

by io.github.DarthSander

check_crypto_signal

Cheap polling for a crypto opportunity you already retrieved: send signal_id plus the known_version you hold and receive whether it changed, the current version, live status (ACTIVE/STALE/INVALIDATED), which change types occurred (score, classification, entry zone, economics, execution blockers, status) and next_check_after — no full signal payload. Built for monitoring an active opportunity over time. Market intelligence only: no execution, no custody, no position sizing. Paid per request.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
signal_idYesSignal id you are monitoring, e.g. 'sig_a1b2c3d4e5f6'
known_versionNoVersion you already hold, e.g. 4; omit it and the answer is always changed=true (no baseline). Poll no earlier than the next_check_after you received.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesThe validated input echoed back, i.e. signal_id and (if you sent one) known_version.
statusNoLive status at call time. ACTIVE = published AND entry window still open, STALE = entry window closed (the hold horizon may still run), INVALIDATED = an invalidation condition triggered. Only ACTIVE is a current new-entry advice.
changedYesTrue when current_version differs from your known_version (or when you supplied no baseline); then call get_crypto_signal for the updated advice.
signal_idYesStable id of the opportunity across versions; the input for every other call in the chain.
checked_atYesWhen we produced this answer (ISO 8601, UTC). The only ISO timestamp in the payload; every other timestamp is unix seconds.
disclaimerYesOur product boundary, verbatim in every paid advice response: market intelligence only, no execution, no custody, no position sizing, and opportunity_score is a heuristic rather than a calibrated win probability.
change_typesYesWhich kinds of change occurred between your baseline and current_version; empty when nothing changed or no baseline was supplied.
source_as_ofYesUnix seconds — freshness of the upstream answer; falls back to our own clock because the check is computed on call.
known_versionYesThe baseline version YOU sent, echoed so the answer can never contradict your input; null when you sent none, and then changed is always true.
current_versionYesThe version the upstream advice system holds right now.
next_check_afterYesUnix seconds — do not poll again before this. Upstream uses now + 300 while ACTIVE and now + 1800 otherwise.
source_disclaimerNoVerbatim disclaimer of the upstream advice system, passed through unedited.
recommended_next_callYesMachine-readable next step in the chain (scan → signal → validate → evidence → check), so you can follow the workflow without documentation. null means there is explicitly nothing useful to call now; next_check_after then says when to come back.

TDQS

A4.7/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 behavioral traits: it's a 'cheap' polling tool, paid per request, returns only changes and status, and explicitly states it does not involve execution, custody, or position sizing. This exceeds the burden of disclosure.

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 extremely concise: three sentences, front-loaded with the core purpose, and no extraneous information. Every sentence adds value.

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?

Given the simple tool with only 2 parameters and an output schema, the description covers everything needed: what is returned, how to use known_version, and the no-execution disclaimer. It is complete and self-contained.

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 coverage is 100%, so baseline is 3. The description adds valuable semantics: it explains that omitting known_version always returns changed=true, and advises to poll no earlier than next_check_after. This goes beyond the schema descriptions.

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 clearly identifies the tool as a lightweight polling mechanism for a previously retrieved crypto signal. It specifies the verb 'poll' and the resource 'crypto signal', and distinguishes itself from full retrieval by stating 'no full signal payload'. The purpose is unambiguous and actionable.

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?

The description provides clear context: 'for a crypto opportunity you already retrieved' and 'built for monitoring an active opportunity over time'. It implies when to use this tool versus full retrieval, but does not explicitly name sibling alternatives. However, the guidance is sufficient for correct usage.

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

All agentdata-nl toolsInspect
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.1/5.0
Disambiguation5/5

Every tool targets a distinct action and domain: country-specific company checks (check_ch_company, check_fr_company, etc.), insolvency checks, crypto signals, x402 network tools, etc. Descriptions are detailed and make boundaries clear, with no two tools appearing to do the same thing.

Naming Consistency5/5

Tool names follow very consistent patterns: 'check_<country>_<entity>' for registers, 'crypto_*' for crypto intelligence, 'x402_*' for x402 network functions, 'screen_*' for screening, and a few free-form names like 'verify_eu_vat' and 'lookup_lei' that still fit the verb_noun style. No mixing of conventions.

Tool Count4/5

39 tools is high but justified by the broad scope: the server aggregates many country-specific checks, insolvency registers, crypto tools, x402 monitoring, and auxiliary functions (like phone number buying, LEI lookup). Each tool serves a clear purpose, and the count is not excessive given the coverage. A slight reduction could be possible by merging some country checks, but overall it's reasonable.

Completeness4/5

The server covers major European company registers (CH, UK, FR, NL, NO, PL, CZ, FI), insolvency checks (NL, FR), sanctions screening, VAT validation, crypto market intelligence, and x402 network tools. It acknowledges gaps (e.g., no German check) and provides fallback tools like 'screen_eu_supplier' and 'file_agent_want'. Minor missing pieces (e.g., Italian company check) keep it from a perfect 5.

Resources