Skip to main content
Glama

agentdata-nl

by io.github.DarthSander

get_crypto_evidence

Historical evidence behind a crypto opportunity: for its strategy (and coin where enough samples exist) the measured populations — detected, blocked, published, expired without entry, completed, wins, losses, time exits — plus win rate over completed outcomes only with a Wilson interval, average/median/total net return, distinct days and coins, ML model evidence status and the measurement window. Real measurements, never fabricated; short windows have wide error bars. Paid per request.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
signal_idYesSignal id, e.g. 'sig_a1b2c3d4e5f6'; returns the measured track record of its strategy (win rate over completed outcomes only, with Wilson interval).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
coinYesCoin the evidence is scoped to; null means too few coin-level samples, so the numbers are strategy-wide.
noteNoVerbatim upstream note on how populations and metrics relate; states that win rate and returns use completed outcomes only.
queryYesThe validated input echoed back, i.e. the signal_id you asked for.
metricsNoMeasured over completed outcomes only (WIN + LOSS + TIME). Anything the source cannot compute is null — never fabricated.
strategyYesStrategy version the evidence is scoped to, e.g. 'momentum-breakout-v1'.
ml_modelsYesMachine-learning models used by this strategy and how far their own validation has come.
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.
populationsNoDisjoint counts over the window, reported apart from the metrics so selection effects stay visible. blocked and expired_without_entry are EXCLUDED from every metric denominator.
window_daysNoLength of the measurement window in days.
source_as_ofYesUnix seconds — freshness of the upstream advice system's answer.
measured_sinceNoUnix seconds — start of the measurement window.
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.
strategy_evidence_statusNoHow far out-of-sample validation has come. UNVALIDATED = no measured outcomes yet, EARLY_EVIDENCE = too few to lean on, VALIDATED = enough measured evidence, REJECTED = measured and found not to work.

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that measurements are real and never fabricated, that short windows have wide error bars, and that it is paid per request. These are useful but incomplete; side effects, rate limits, or authorization needs are not mentioned.

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 description is somewhat verbose, listing multiple populations and metrics. It front-loads the main purpose, but the lengthy enumeration could be more concise. Each sentence adds value, but the structure could be improved for readability.

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 presence of an output schema, the description adequately explains the key returned data (populations, win rate, etc.) and includes caveats. It covers the essential aspects for an agent to understand what the tool does, though sibling differentiation would strengthen completeness.

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?

The schema description covers the single parameter 'signal_id' fully, including a pattern and example. The tool description adds general context but does not enhance parameter semantics beyond what the schema already provides. Baseline 3 is appropriate due to 100% coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool returns 'Historical evidence behind a crypto opportunity' and enumerates specific metrics, indicating a retrieval function. However, it does not explicitly differentiate from siblings like 'crypto_track_record' or 'crypto_verdict', which may have overlapping purposes.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description purely states what the tool does without any context on when it is appropriate or when to avoid it, leaving the agent to infer usage indirectly.

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