agentdata-nl

file_agent_want

File what you want to buy from an agent-facing API and cannot buy today. Optional kind is typically one of coin, country, vies_country, monitor_host, sms_service — free-form values possible. The $0.01 fee is there to keep intents honest, not to sell you anything: it is not a purchase of the capability and no promise that it gets built. Optionally add the price per call you would pay and your expected monthly volume. Free alternative: POST /agent/request.

Input Schema

TableJSON Schema

Name	Required	Description
`kind`	No	Optional coverage kind, typically one of 'coin', 'country', 'vies_country', 'monitor_host', 'sms_service' — free-form values possible. Sending it makes your intent countable in the aggregate
`want`	Yes	What you want to buy and cannot buy today, in your own words
`value`	No	Optional coverage value, e.g. 'PT'. Same character rules as request_capability
`max_price_usd`	No	Optional: USD per call you would actually pay. Budget-backed intents outrank anonymous wishes
`expected_calls_per_month`	No	Optional: calls per month you expect to make

Output Schema

TableJSON Schema

Name	Required	Description
`note`	Yes	Verbatim boundary of this endpoint: the fee keeps intents honest, it is not a purchase of the capability and no promise that it gets built; your intent is counted aggregated and anonymised in x402_demand_report, and your wallet and text are never resold.
`query`	Yes	The validated input echoed back, so the record can never contradict what you sent.
`recorded`	Yes	Always true on a 200: the intent is stored. A failure to store is a 503 and is not charged.
`intent_id`	Yes	Opaque reference for this intent, e.g. 'want_a1b2c3d4e5f6'. Quote it if you follow up; it is random rather than sequential, and there is no lookup endpoint.
`checked_at`	Yes	When we produced this answer (ISO 8601, UTC). The only ISO timestamp in the payload; every other timestamp is unix seconds.

TDQS

A4/5.0

Behavior4/5

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

Without annotations, the description carries the burden. It explains that the $0.01 fee is not a purchase and that there is no promise the feature will be built. It also mentions that optional parameters like max_price_usd affect ranking. No contradictions.

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

Conciseness4/5

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

The description is fairly concise, covering main points in a few sentences. It front-loads the purpose but could be more structured with bullet points or clearer separation of ideas. Still, it's not overly verbose.

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?

With an output schema present and 5 parameters (1 required), the description provides enough context: purpose, fee explanation, alternative, optional parameters. It does not detail return values or errors, but output schema likely covers that.

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% with good descriptions, so baseline is 3. The description adds extra meaning by explaining the fee motivation, typical kind values, and that budget-backed intents outrank others. This goes beyond the schema.

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 the tool's purpose: to file a request for a capability that is not yet available. It uses specific verb 'File' and resource 'what you want to buy', and distinguishes itself from siblings implicitly by being a unique action among many checking tools.

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?

It provides context on when to use (when you want something not buyable) and lists optional parameters. It mentions a free alternative (POST /agent/request) and describes the fee's purpose. However, it could be more explicit about scenarios where this tool should be avoided in favor of other tools.

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

All agentdata-nl 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.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

Need Help?